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Reply to Office Action of February 27, 2008 



Staniar et al. 
Appl. No. 10/750,030 



Remarks 

Reconsideration of this Application is respectfully requested. 
Status of Claims 

Claims 1-18 are pending in the application, with claim 1 being the independent 
claims. Claims 19 and 20 were previously withdrawn without prejudice to or disclaimer 
of the subject matter therein. No changes to the claims have been made, and no new 
matter has been added. Based on the following remarks, Applicants respectfully request 
that the Examiner reconsider all outstanding objections and rejections and that they be 
withdrawn. 

Rejections under 35 U.S.C. § 102 

Claims 1-3, 6-8, 10-12, and 15-16 were rejected under 35 U.S.C. § 102(b) as 
being allegedly anticipated by U.S. Application Publication No. 2007/0055582 to Hahn- 
Carlson ("Hahn-Carlson"). Applicants respectfully traverse. 

Hahn-Carlson does not qualify as a valid reference under 35 U.S.C. § 102(b). 
According to 35 U.S.C. § 102(b), "[a] person shall be entitled to a patent unless ... the 
invention was patented or described in a printed publication in this or a foreign country 
. . . more than one year prior to the date of the application for patent in the United States. 
35 U.S.C. § 102(b) (2002) (emphasis added). Hahn-Carlson is not a patent, and Hahn- 
Carlson was printed on March 8, 2007, after the filing date of the instant application — 
not before. Thus, Hahn-Carlson does not qualify as a valid reference under 35 U.S.C. § 
102(b). 
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Hahn-Carlson also does not qualify as a valid reference under 35 U.S.C. § 102(e). 
A published patent application would qualify as a valid reference under 35 U.S.C. § 
102(e) against the claims of the instant application only if the published patent 
application has an effective filing date prior to the filing date of the instant application. 
See 35 U.S.C. § 102(e) (2002). Although the actual filing date of Hahn-Carlson {i.e., 
October 6, 2006) is after the filing date of the instant application {i.e., December 31, 
2003), Hahn-Carlson claims the benefit of several earlier filing dates based on several 
non-provisional applications having filing dates that pre-date the filing date of the instant 
application. Thus, in order for Hahn-Carlson to qualify as a valid reference under 35 
U.S.C. § 102(e), "the subject matter used in the rejection must be disclosed in the earlier- 
filed application[s] in compliance with 35 U.S.C. 112, first paragraph." MPEP § 
2136.03(IV). However, the earlier-filed applications do not contain the subject matter 
relied on by the Examiner. 

Hahn-Carlson is a continuation-in-part (CD?) of two applications that have filing 
dates prior to the filing date of the instant application: 

(i) U.S. Application No. 10/437,405 filed May 12, 2003 (corresponding to 
U.S. Publication No. 2004/0010463, which is attached hereto as 
Exhibit A); and 

(ii) U.S. Application No. 09/527,717 filed March 17, 2000 (attached 
hereto as Exhibit B). 

In addition, the '405 application and the '717 application are each CIPs of U.S. 
Application No. 09/259,657 (now U.S. Patent No. 6,571,149, which is attached hereto as 
Exhibit C). Although the '405, '717, and '657 applications each have filing dates that 
pre-date the filing date of the instant application {i.e., December 31, 2003), none of these 
references disclose the subject matter that the Examiner relied on in the rejection of 
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claims 1-3, 6-8, 10-12, and 15-16. See Exhibits A-C. Thus, Hahn-Carlson is not a valid 

reference under 35 U.S.C. § 102(e). 

Because Hahn-Carlson does not qualify as a valid reference under 35 U.S.C. § 

102(b) or § 102(e), Hahn-Carlson cannot anticipate claims 1-3, 6-8, 10-12, and 15-16. 

Accordingly, Applicants respectfully request that the rejection of claims 1-3, 6-8, 10-12, 

and 15-16 be reconsidered and withdrawn. 

Rejections under 35 U.S.C. § 103 
Claims 4, 5, 17, and 18 

Claims 4, 5, 17, and 18 were rejected under 35 U.S.C. § 103(a) as being allegedly 
unpatentable over Hahn-Carlson in view of U.S. Application Publication 2005/0027654 
to Adrian ("Adrian"). Applicants respectfully traverse. 

As set forth above, Hahn-Carlson does not qualify as a valid reference under 35 
U.S.C. § 102(b) or § 102(e). Thus, Hahn-Carlson cannot properly be used in a rejection 
under 35 U.S.C. § 103(a). Therefore, the rejection of claims 4, 5, 17, and 18 under 35 
U.S.C. § 103(a) is improper. Accordingly, Applicants respectfully request that the 
rejection of claims 4, 5, 17, and 18 be reconsidered and withdrawn. 

Claims 9, 13, and 14 

Claims 9, 13, and 14 were rejected under 35 U.S.C. § 103(a) as being allegedly 
unpatentable over Hahn-Carlson in view of Adrian, and further in view of U.S. Patent 
No. 6,167,385 to Hartley-Urquhart ("Hartley-Urquhart"). Applicants respectfully 
traverse. 

As set forth above, Hahn-Carlson does not qualify as a valid reference under 35 
U.S.C. § 102(b) or § 102(e). Thus, Hahn-Carlson cannot properly be used in a rejection 
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under 35 U.S.C. § 103(a). Therefore, the rejection of claims 9, 13, and 14 under 35 
U.S.C. § 103(a) is improper. Accordingly, Applicants respectfully request that the 
rejection of claims 9, 13, and 14 be reconsidered and withdrawn. 

Conclusion 

All of the stated grounds of objection and rejection have been properly traversed, 
accommodated, or rendered moot. Applicants therefore respectfully request that the 
Examiner reconsider all presently outstanding objections and rejections and that they be 
withdrawn. Applicants believe that a full and complete reply has been made to the 
outstanding Office Action and, as such, the present application is in condition for 
allowance. If the Examiner believes, for any reason, that personal communication will 
expedite prosecution of this application, the Examiner is invited to telephone the 
undersigned at the number provided. 

Prompt and favorable consideration of this Reply is respectfully requested. 

Respectfully submitted, 

Sterne, Kessler, Goldstein & Fox p.l.l.c. 



Jonathan Tuminaro 
Agent for Applicants 
Registration No. 61,327 





1 100 New York Avenue, N.W. 
Washington, D.C. 20005-3934 
(202) 371-2600 



810575_1.DOC 



Atty. Dkt. No. 2348.0050000 



Exhibit A 



US 20040010463A1 

(19) United States 

(12) Patent Application Publication (m» Pub. No.: US 2004/0010463 Al 

Jan. 15, 2004 



Hahn-Carlson et al. 



(43) Pub. Date: 



(54) AUTOMATED TRANSACTION PROCESSING 
SYSTEM AND APPROACH 

(76) Inventors: Dean W. Hahn-Carlson, St. Paul, MN 
(US); Richard G. Langer, Lakeville, 
MN (US); Kevin M. Armstrong, Ham 
Lake, MN (US); Weiwen Xie, 
Woodbury, MN (US) 

Correspondence Address: 
Crawford Maunu PLLC 
Suite 390 

1270 Northland Drive 
St. Paul, MN 55120 (US) 

(21) Appl. No.: 10/437,405 

(22) Filed: May 12, 2003 

Related U.S. Application Data 

(63) Continuation-in-part of application No. 09/259,657, 
filed on Feb. 26, 1999, now Pat. No. 6,571,149, which 
is a continuation of application No. 08/748,243, filed 
on Nov. 12, 1996, now Pat. No. 5,910,896. 



(60) Provisional application No. 60/379,561, filed on May 
10, 2002. 

Publication Classification 

(51) Int. CI. 7 G06F 17/60; G06F 17/00; 

G06G 7/00 

(52) U.S. CI 705/39; 705/26; 705/37; 705/400 



(57) 



ABSTRACT 



Transaction management for contract and contract-related 
approaches is facilitated. According to an example embodi- 
ment of the present invention, a transaction management 
computer is programmed to automatically set contract terms 
for a transaction based on business rules previously estab- 
lished between parties to a transaction. In one implementa- 
tion, the transaction management node automatically derives 
a contract term including a pricing-related term for a trans- 
action between a buyer and seller using contract information 
therefor. In one instance, previously-agreed-upon price 
approaches, such as fixed pricing, seller-controlled pricing, 
quantity-related tiered pricing and pricing management 
schemes are stored and used by the transaction management 
node to automatically derive the prices. With these 
approaches, pricing disputes that can occur after a transac- 
tion has been processed are reduced and/or eliminated. 
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AUTOMATED TRANSACTION PROCESSING 
SYSTEM AND APPROACH 

RELATED DOCUMENTS 

[0001] This patent document is a continuation-in-part of 
U.S. patent application Ser. No. 09/259,657 (USBA.002C1), 

filed Feb. 26, 1999 now U.S. Pat. No. , which is a 

continuation of U.S. patent application Ser. No. 08/748,243, 
filed on Nov. 12, 1996, now U.S. Pat. No. 5,910,896 entitled, 
"Shipment Transaction System and an Arrangement 
Thereof." This patent document further claims priority to 
U.S. Provisional Patent Application Serial No. 60/379,561 
(USBA.101P1) and filed on May 10, 2002, to which priority 
is claimed under 35 U.S.C. §120 for common subject matter, 
and which claims priority to the same U.S. patent document 
(U.S. Pat. No. 5,910,896), which is fully incorporated herein 
by reference. 

FIELD OF THE INVENTION 

[0002] The present invention is directed to communica- 
tions and data processing and, more specifically, to commu- 
nications and data processing involving the establishment 
and implementation of contracts. 

BACKGROUND 

[0003] Operational management of contractual and trans- 
actional interactions between buyers, sellers and others 
involved in the exchange of products for purposes of com- 
ineice have lypicaiiy been labui auu ume intensive, uener- 
ally, the processes of managing transactions between busi- 
ness entities have been unduly burdensome and inefficient. 
The various parties involved in a transaction typically 
change proposed terms and aspects of a proposed transaction 
on a concurrent and/or iterative basis. Data representing 
each corporate participant's view of the interaction is stored 
across one or more enterprise systems managed by that 
particular corporate participant and not accessible by other 
corporate participants. Consequently, it can be difficult to 
know which draft document represents the most current 
information about the interaction and whether the parties to 
the transaction have a common understanding. Where the 
corporate participants have communicated electronically 
(e.g., via email and Internet-enhanced communications), 
these document-synchronization difficulties have been com- 
pounded by an increased number of co-existing draft docu- 
ments being viewed by the parties. Commercial transactions 
then become more difficult as business entities attempt to 
perform business with each other. 

[0004] A typical commercial interaction between a seller 
offering a product and a buyer desired to acquire that product 
moves through multiple steps. First, the buyer and the seller 
negotiate an agreement as to the price the buyer will pay. 
When this agreement covers an extended period of time it is 
typically formalized in a contract or catalog. Contracts and 
catalogs are typically maintained by the seller in a seller- 
managed computer system that is separate from the com- 
puter system or systems which the seller uses to accept 
orders, fulfill orders and generate invoices. When the 
invoice system used by the seller to bill the buyer has a 
different price file than is resident in the seller-managed 
contract system, pricing exceptions will occur which will 
increase the cost of the interaction because buyer and seller 



personnel will have to resolve the differences a transaction 
can be completed. The problem can be compounded when 
the buyer loads the current contract prices into its procure- 
ment system for determination of whether the seller is 
billing correctly during the pre-payment order/invoice rec- 
onciliation process. All of seller's invoicing systems could 
be representing the current contract while one or more of the 
buyer's systems still represent an expired or not yet active 
contract. Some or all of the seller's invoicing systems could 
be representing expired or not yet active contracts while all 
of the buyer's procurement systems are up to date. The 
number of combinations of events leading to transaction 
misunderstandings and disagreements contributes signifi- 
cantly to the overall cost of settling for the exchange of 
products. As a further complication, the contract contents, 
the order, the invoice and other documents representing the 
transaction and required to settle the transaction often only 
exist in paper form for access to the individuals attempting 
to resolve exceptions. Further, the data that does exist 
electronically is often scattered across numerous applica- 
tions such as accounts payable, accounts receivable, pur- 
chasing, accounting, buyer or seller group, shipping, and 
receiving. Moreover, where each buyer does business with 
many sellers and each seller does business with many 
buyers, tracking such drafts becomes increasingly more 
difficult. 

[0005] One type of transaction for which the above diffi- 
culties apply is a shipping transaction. Traditional 
approaches have lead to many challenges to managing 
transactions t-w.oen one shi^w and one Ca^r. Typically, 
however, there are multiple carriers and shippers involved in 
multiple transactions, which makes the management process 
more complex, and that much more time-consuming and 
inefficient. The process is labor intensive in that it relies on 
physically matching the hard copy of a bill of lading (BOL) 
for proof of delivery with the hard copy invoice and then 
trying to apply the terms of a hard copy contract to calculate 
whether the invoice amount is proper to pay. Exceptions 
need to be communicated to the trading partner, often 
involving faxing or mailing paper copies of support mate- 
rials. Responses to requests for information often results in 
more paper copies with hand-written annotations that alter 
the understanding of how the transaction actually transpired. 
The ensuing series of repetitive and time consuming steps 
are a source of additional operational expense for both buyer 
and seller. Also, each BOL is often rated multiple times by 
multiple parties creating excessive redundancy. 

[0006] Due to such difficulties and convoluted processes, 
traditional shipment transaction management systems are 
highly susceptible to billing errors and fraud. For example, 
there has been no connection between the delivery of goods 
and when the shipper is billed for delivery. This may result 
in double billing, no billing at all, or overbilling the shipper 
for freight delivery charges. Also, auditing errors may occur, 
which results in incorrect billing or payment. In addition, the 
carrier waits a disproportionately long time for payment 
while the invoice is being audited and/or disputed. For 
example, traditionally, a delivery takes about five days 
whereas payment takes about forty-five days. This delay 
adversely affects the carrier's working capital resources 
which, in turn, raises the carrier's cost of doing business and 
raises the prices the carrier must charge to earn the economic 
return required to remain in business. 
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[0007] Additional costs arise as a result of the existing 
inefficiencies. Many of the costs are individually small, but 
very large in the aggregate. For example, the carrier incurs 
administrative costs including: the cost to create and deliver 
the initial invoice, costs of resolving billing disputes, costs 
of providing a signed copy of the BOL to the shipper, and 
costs of posting accounts receivable. The shipper incurs 
similar administrative costs to receive the bill, match it with 
the BOL, manually check the contracts to determine if 
pricing is correct, generate and deliver payment to the 

[0008] Another challenge present in many traditional sys- 
tems involves the incompatibility of product and service 
(hereinafter the terms "product" and/or "service" are col- 
lectively referred to as "product") reference identifiers 
between buyers, sellers and other related entities (e.g., a 
distributor or group purchase organization (GPO)). When 
multiple reference identifiers are used, tracking and recon- 
ciling business transactions become more difficult. The 
complexity of modern business has also lead to expensive 
administrative costs associated with commercial transac- 
tions. Administrative costs include personnel, software, 
hardware, and entire departments created for managing 
commercial transactions to ensure accurate and timely bill- 
ing and payment. Even with the expensive administrative 
cost, most transactions have typically relied on paper as the 
means of communicating within and between corporations. 
Paper copies are expensive and difficult to track and are not 
simultaneously accessible from geographical disparate loca- 
tions. Dispute's run also occur with various nane.r conies 
circulating within and between corporations (e.g., price 
discrepancies, short pays, and lengthy price disputes). These 
disputes can result in burdensome and lengthy negotiations, 
further frustrating both the buyer and seller. Additionally, the 
disputes can lead to a deterioration or possibly extinction of 
the relationship between the buyer and seller. Further costs 
are incurred if new buyers or sellers need to be found. 
[0009] Most industries are quite competitive and any cost 
savings are therefore important. Administrative costs are 
targeted for reduction as no revenue is directly generated 
from administrative functions. However, administrative 
costs associated with commercial transactions have been 
difficult to reduce in the current business environment with 
widely diffused data. 

[0010] The above and other difficulties in the management 
and coordination of business transactions have presented 
administrative and cost challenges to business entities on 
both the buyer and seller ends of transactions, as well as 
those involved in other aspects of such transactions, includ- 
ing distributors and buying organizations (such as GPOs) 
who negotiate contracts on behalf of a large, disparate group 
of buyers. 

SUMMARY 

[0011] The present invention is directed to overcoming the 
above-mentioned challenges and others related to the types 
of devices and applications discussed above and in other 
applications. The present invention is exemplified in a 
number of implementations and applications, some of which 
are summarized below. 

[0012] In a first example embodiment, the present inven- 
tion is directed to a transaction management system that 



manages transactions using an approach that is based on 
business rules previously established by buyer(s) and sell- 
ers). The transaction management system includes a com- 
puter and communications node adapted for deriving prices 
for transactions as a function of pricing rules that are agreed 
upon by buying and selling entities related to the transaction. 

[0013] According to another example embodiment of the 
present invention, a database approach is implemented for 
communications and/or transaction management regarding 
contract and price information. Buyer(s) and seller(s) can set 
pricing, period in which pricing is to be effective, and other 
contract-related aspects in advance of any transaction to be 
performed under that contract, and these aspects can be 
implemented in connection with further transactions, with 
modifications to these aspects being implemented manually 
and/or automatically. In one implementation, the responsi- 
bility of reviewing, accepting, and/or disputing new or 
updated prices is oriented to the buyer of products being 
contracted for. Sell prices can be set, for example, for 
particular buyers, purchasing organizations, classes of buy- 
ers or all buyers, with a particular price being associated 
with a transaction as a function of the defined characteristics 
of the buyer. Prices can also be set as a function of definable 
terms associated with buyers and/or sellers, with a final price 
being automatically accepted in response to the definable 
terms. In another implementation, where prices are disputed, 
the buyer and seller work together to reach terms acceptable 
to both parties, using a database approach to record nego- 
tiated terms. 

[0014] With the approaches discussed in the previous 
paragraph, many of the challenges discussed in the back- 
ground above (e.g., price discrepancies, short pays, and 
lengthy price disputes) are minimized or completely elimi- 
nated. For instance, a single source of product prices and 
contracts can be implemented for usage by a variety of 
buyers and/or sellers, with communications and/or negotia- 
tions for a particular transaction being selected based on the 
buyer(s) and/or seller(s) involved. With all relevant data 
available to all parties and systems at a central source the 
synchronization issues in business transactions are elimi- 
nated. Buyers and sellers can collaboratively review and 
approve the contract prior to its use without either party 
necessarily having to allow the other access to its enterprise 
systems. Use of the approved data from a central transaction 
management system ensures that both the buyer and seller 
are using the most recent agreed upon price. In addition, the 
centralized transaction management system records the pre- 
cise time of agreement and the identity of the party execut- 
ing the agreement. 

[0015] In another example embodiment, an electronic 
interface is configured and arranged for interfacing with the 
transaction management system discussed above. The elec- 
tronic interface is adapted to execute search functions and 
access information pertaining to contract terms, such as 
product prices, contracts, effective dates, and price notes. In 
one implementation, the electronic interface is adapted for 
providing user identification data for use by the transaction 
management system for controlling aspects of the interface, 
such as authorization, recordation, display and functional 
capabilities. With this approach, a single source of electroni- 
cally accessible information can be implemented for finding 
products that suit user needs in an efficient manner. 
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[0016] The above summary of the present invention is not 
intended to describe each illustrated embodiment or every 
implementation of the present invention. The figures and 
detailed description that follow more particularly exemplify 
these embodiments. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0017] The invention may be more completely understood 
in consideration of the detailed description of various 
embodiments of the invention in connection with the accom- 
panying drawings, in which: 

[0018] FIG. 1 shows an arrangement and approach for 
transaction management, according to an example embodi- 
ment of the present invention; 

[0019] FIG. 2 shows another arrangement and approach 
for transaction management, according to another example 
embodiment of the present invention; 
[0020] FIG. 3A shows an automated transaction approach 
involving a collaborative contracts manager, according to 
another example embodiment of the present invention; 
[0021] FIG. 3B shows another automated transaction 
approach involving a collaborative contracts manager, 
according to another example embodiment of the present 
invention; 

[0022] FIG. 4A shows an approach to automated contract 
performance using a collaborative contracts manager, 
according to another example embodiment of the present 

[0023] FIG. 4B shows an approach for automated pricing 
business rule application, in connection with another 
example embodiment of the present invention; and 
[0024] FIGS. 5A-5D show approaches for establishing 
automated transaction management in connection with a 
variety of users and according to other example embodi- 
ments, wherein: 

[0025] FIG. 5A shows a manufacturer-based per- 
spective; 

[0026] FIG. 5B shows a distributor-based perspec- 
tive; 

[0027] FIG. 5C shows a retail buyer-based perspec- 
tive; and 

[0028] FIG. 5D shows a group purchasing organiza- 
tion-based perspective. 

[0029] While the invention is amenable to various modi- 
fications and alternative forms, specifics thereof have been 
shown by way of example in the drawings and will be 
described in detail. It should be understood, however, that 
the intention is not necessarily to limit the invention to the 
particular embodiments described. On the contrary, the 
intention is to cover all modifications, equivalents, and 
alternatives falling within the spirit and scope of the inven- 
tion as defined by the appended claims. 

DETAILED DESCRIPTION 

[0030] The present invention is believed to be applicable 
to a variety of different types of communications and finan- 
cial process management approaches, and has been found to 



be particularly useful for applications involving the opera- 
tional implementation and application of pricing to transac- 
tions, payments, tracking and related aspects thereof. While 
the present invention is not necessarily limited to such 
approaches, various aspects of the invention may be appre- 
ciated through a discussion of various examples using these 
and other contexts. 

[0031] According to an example embodiment of the 
present invention, a central transaction management 
arrangement uses transaction information for buyers and 
sellers of products to automatically derive pricing and/or 
payment options for individual transactions. The transaction 
information may include, for example, the identities of the 
buyer and seller, the products being purchased, the date of 
the purchase and the specific contract under the terms of 
which the transaction is being executed. For instance, spe- 
cific contracts under the terms of which a transaction is 
being prosecuted may include prices agreed upon between a 
buyer and seller for a particular item and/or rules agreed 
upon for setting certain prices between a buyer and seller. In 
one instance, prices associated with a particular product are 
automatically set by the central transaction management 
arrangement to correspond to transaction information 
assigned to a particular buyer of the products. The prices 
may be set, for example, using predetermined prices agreed 
to by the buyer and seller involved in the transaction. In 
another implementation, pricing arrangements such as quan- 
tity discounts, group discounts and conditional price vari- 
ances (e.g., an acceptable percentage of variance in cost 
associated with for fluctuating shinning costs, nrnrlurt prices 
and others) are further automatically implemented in 
response to the transaction information and the approved 
contract details in the central transaction management 
arrangement. 

[0032] In a more particular implementation, the transac- 
tion management arrangement is adapted to use reference 
contract information regarding pricing from a particular 
manufacturer, for example, offered to a particular buyer 
based on that buyer's membership in a group purchasing 
organization. When a buyer requests a transaction for prod- 
ucts covered by the reference contract from a manufacturer- 
authorized distributor, the transaction management arrange- 
ment uses the reference contract information and adds the 
distributor's markup to derive a final price for the buyer. In 
another instance, the transaction management arrangement 
derives the seller's final price by applying the seller's 
specific discount or surcharge to an industry standard price 
list (e.g., motor freight tariff). In another instance, the 
reference contract information is specific to a particular 
buyer, or to a group purchasing organization (GPO) to which 
the particular buyer belongs. In this manner, the reference 
contract and any contract between a buyer and the GPO are 
nested, with the nested contracts being used to derive a 
particular term for a transaction for goods. In still another 
implementation, the transaction management arrangement is 
adapted to restrict use of the reference contract to selected 
buyers and, in response to a buyer request, first determine 
whether the particular buyer making the request is eligible to 
use the reference contract. 

[0033] Various example embodiments of the present 
invention may provide advantage to applications such as 
discussed in U.S. Pat. No. 5,910,896, referenced above. For 
example, as discussed in the previous paragraph, variances 
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in shipping costs, managed using one or more approaches 
not inconsistent with those discussed in U.S. Pat. No. 
5,910,896, can be automatically implemented and approved 
using the stored transaction information. In addition, for 
general information regarding transactions and for specific 
information regarding implementations to which various 
example embodiments of the present invention are directed, 
reference may be made to the documents attached to the 
provisional application identified above and to which prior- 
ity is claimed. 

[0034] Another example embodiment of the present 
invention is directed to a database system adapted for 
automated transaction management that provides a single 
source of product prices and contracts. In advance of any 
transaction, prospective buyers and sellers negotiate and/or 
validate prices and contracts, or simply validate the elec- 
tronic representation of prices and contracts negotiated 
through other means. The buyer reviews, accepts and/or 
disputes updated contract term(s). Once the buyer accepts a 
contract, a processing center stores the accepted contract and 
activates the contract for current and/or future business 
transactions. A collaborative contracts manager applies busi- 
ness rules for actual performance of the contract, with the 
buyer and seller involved in the transaction defining the 
applicable business rules. Business rules may, for example, 
be derived from and/or include buyer and/or seller profile 
information that includes contract-related data such as prod- 
uct, pricing, shipping, payment terms, currency type, cus- 
toms information and other typical contract data. Further- 
iii^iv, the busing .-los can b± o^ivJ in a database at C 
collaborative contracts manager processor. All pricing infor- 
mation and business rules are retrievable by a centralized 
transaction manager or by applications remote from the 
collaborative contracts manager such as those located at the 
buyer or seller location. Potential performance disputes are 
automatically resolved by the collaborative contracts man- 
ager, for instance, by using the predefined and accepted 
business rules to automatically arrive at performance char- 
acteristics prior to executing a transaction. By approaching 
transactions in this manner, many of the shortcomings of 
traditional systems (e.g., price discrepancies between dif- 
ferent entities of a corporation, short pays, and lengthy price 
disputes) are minimized or completely eliminated. 

[0035] The buyer and seller profiles discussed herein may 
include a variety of information for use in transaction 
management and otherwise. For instance, a typical such 
profile includes one or more of the following data: general 
ledger charts of accounts, identification of computer systems 
submitting contract or transaction data to the collaborative 
contracts manager, customer lists, vendor lists, contract and 
price approval policies, transactional approval policies, 
business rules, operational roles (e.g., defining what func- 
tions a user associated with that role can perform), organi- 
zational hierarchy (e.g., defining how much of a company's 
data universe a user associated with a particular organiza- 
tional node can access), and users. Seller customer list 
profiles may also include information further defining the 
business relationship with the customer from the Seller's 
perspective, for example, such as a retail buyer relationship, 
wholesale buyer relationship, etc. Buyer vendor (e.g., seller 
or distributor) list profiles may also include information 
further defining the business relationship with the vendor 
from the Buyer's perspective. Such seller and buyer rela- 



tional information may, for example, include those discussed 
further below in connection with FIGS. 5A-5D. 

[0036] In another example embodiment, a central database 
and transaction management system uses four types of data 
to manage transactions. The types of data include security/ 
privilege data, access-control data, entity profile data, and 
business rules data. Security/privilege and access control 
data types provide the appropriate levels of protection (e.g., 
log-in and password data) to the data stored and processed 
by the system and also provide access to such information at 
various levels/hierarchies within each company. For 
example, once a company is enrolled or registered to use the 
system, initial implementation includes definition of opera- 
tional filters that define how a user (within an organization 
level or otherwise) can access the transaction information 
and/or interact with the system. Such operational filters can 
include, for example, filters that limit the extent to which a 
user (e.g., employee or agent of the company) can: approve/ 
hold/deny/cancel/update transactional steps, view transac- 
tion-related data, and analyze the data. 
[0037] The entity profile data type permits the system to 
track the enrolled companies, their vendor identifier num- 
bers, the associated accounts and contracts, and provides for 
mapping between organizational levels within enrolled com- 
panies and between enrolled companies; where this mapping 
includes tracking of the various entities as well as the 
products at issue for processing transactions. Using the 
entity profile data type, the business rules data type are 
defined by the enrolled companies for their anticipated 
transactive io permit the system lo process trauoei^uons 
with specified sets of characteristics, for example, to support 
self-invoicing, and to implement EIPP (electronic invoicing 
presentment and payment) with or without (product-ID) 
matching. With the above data in place, the system permits 
the respectively enrolled organizations to continue conduct- 
ing business using descriptors meaningful to their organi- 
zations, while interpreting and processing these descriptors 
at the system according to the entity profile data and the 
business rules data. 

[0038] Once established, a variety of transactions and 
transaction management activities can be implemented 
using these data types. In one example, the above data types 
are used to derive a specific term by which a transaction is 
managed (e.g., to derive a price to assign to a particular 
transaction, to derive a particular mark-up to add to a base 
price or to identify a particular product requested by a 
user-specific identification number). 

[0039] In another example, the data is used to execute a 
variety of financial data-processing modules within the 
central database and transaction management system. Six 
kinds of financial data-processing modules are exemplified 
and shown and discussed in an attachment hereto which is 
identified as Appendix A (including seventeen pages). 
[0040] In one particular implementation, profile informa- 
tion such as business rules, operational roles, authorization 
levels and/or other attributes are specific to particular levels 
and/or individuals within a particular entity. This profile 
information is stored in the central database and transaction 
management system discussed above and used for imple- 
menting transactions. For example, when a particular com- 
pany includes different subsidiaries, divisions or locations, 
profile information can be tailored for the particular source. 
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Certain profile information can also be implemented to 
supersede other profile information, for example, when a 
particular subsidiary is assigned different specific pricing 
terms, relevant to another subsidiary of a common company. 
[0041] In another example embodiment of the present 
invention, an electronic interface is configured and arranged 
for providing user access to a collaborative contracts man- 
ager such as discussed above. Purchases of goods can be 
made using the electronic interface to communicate with the 
collaborative contracts manager and pricing rules engaged 
thereby. The electronic interface also facilitates user-ex- 
ecuted search functions for accessing information such as 
product information, product prices, contracts and price 
notes. Access to information via the collaborative contracts 
manager by the user interface is adaptively controllable, for 
instance, using authorization approaches including user 
identification, interface identification, password access and 
others. With this approach, a single source of electronically 
accessible information is made available for pricing, con- 
tracting and related matters to a multiplicity of parties, 
which allows users associated with those parties to effi- 
ciently find a product or products that suit their needs. 

[0042] In another example embodiment, a transaction 
management system stores information for buyers and sell- 
ers and communicates therewith using an identification 
approach for users at the buyer and/or seller level. The 
system controls access to the stored information as a func- 
tion of user identification (ID), with access parameters 
controlled for processes such as contract modification, price 
muuuication, display cunfiguialioii, access lo die stored 
information for that particular user and others. Using seller 
offerings that make up at least part of the stored information 
for a particular seller, as well as buyer access controls, the 
seller offerings are automatically configured for usage by the 
individual users. The automatic configuration may, for 
example, include price, delivery and payment options. In 
response to the seller offerings and other stored information, 
the transaction management system is adapted for accepting 
purchase requests from buyers and communicating the pur- 
chase requests to the seller from which the purchase is to be 
made. The transaction management system is further 
adapted for accepting acknowledgment of receipt by the 
buyer either manually (e.g., an individual buyer logs into the 
system with a user ID and confirms receipt) or electronically 
(e.g., buyer's inventory receiving systems automatically 
generate and transmit a detailed notice of receipt). Once 
receipt is acknowledged, the system communicates that 
acknowledgment to the seller. In one implementation, the 
system is further adapted for automatically paying the seller 
in response to the receipt acknowledgment. In another 
implementation, the system is further adapted to invoice the 
buyer for the purchase. 

[0043] In another implementation, the transaction man- 
agement system discussed in the preceding paragraph is 
further adapted for accepting a receipt of purchase acknowl- 
edgment including receipt characteristics. For example, 
characteristics such as total acceptance of goods, partial 
acceptance of goods and rejection of goods at the invoice or 
receipt line item level can be included in the acknowledg- 
ment. This information can be required as being verified for 
ensuring compliance before payment for a transaction is 
executed. An invoice for a particular transaction can be 
updated with this and other transaction-fulfillment-related 



information. Using this approach, problems with received 
purchases, such as damaged goods, improper goods, etc., 
can be readily addressed. The various invoicing and pay- 
ment-related characteristics are correspondingly modified 
(e.g., payment is only made for accepted portions of goods, 
or credit for the cost of returning goods is granted). 

[0044] Transaction billing and payment is managed using 
an approach including third-party control, according to 
another example embodiment of the present invention. 
Buyer and seller entities involved in a transaction use a third 
party to coordinate purchases and payment thereof. The 
seller communicates offerings (e.g., goods with price and 
shipment characteristics) to the third party, and buyers 
access the offerings via the third party. When a request for 
purchase of the seller offerings by a buyer is made to the 
third party, the third party submits the request to the seller 
and pays the seller for the purchase. In one implementation, 
the payment is not effected until the buyer has acknowledged 
receipt. The third party then charges one or both of the seller 
and buyer a fee for handling the purchase, and correspond- 
ingly bills the buyer for the purchase. 

[0045] In a more particular example embodiment, buyers 
and sellers approve contracts using a collaborative contract 
manager and submit order and invoice quantities for execut- 
ing the contracts to a central processor arrangement (e.g., 
including the collaborative contract manager). The central 
processor arrangement then uses the prices from the col- 
laborative contracts manager to establish the amount of the 
settlement (i.e., price) between the buyer and the seller. In 
one instance, the seller uses the collaborative contracts 
manager as the central repository called by various seller 
fulfillment systems. In another instance, the buyer uses the 
collaborative contracts manager as the central repository 
called by various buyer procurement systems. 

[0046] In still another example embodiment of the present 
invention, a collaborative contracts manager is adapted to 
assign a pricing term to transactions using a product iden- 
tification (ID) matching approach and business rules. The 
product ID matching approach involves matching a product 
ID to business rules and, therefrom, deriving a pricing term 
for purchase of the product to which the ID relates. For 
example, when buyers and sellers, or even different buyers 
within a single organization, use different product IDs for 
the same goods, the collaborative contracts manager 
matches the buyer's product ID to a seller product ID and, 
therefrom, uses business rules to derive a price for the 
particular product to which the product IDs refer. In a more 
particular implementation, the product ID includes embed- 
ded information relating to the product and other character- 
istics of the transaction, such as the origin of the product, the 
destination of the product and a mode of shipping for the 
product. In another implementation, the product ID includes 
information relating to a line item of a particular contract 
where a product is fisted. 

[0047] FIG. 1 is a communication system 100 including a 
collaborative contracts manager 110 for handling business 
transactions between a seller and a buyer, according to 
another example embodiment of the present invention. The 
communications system 100 includes a seller terminal 122 
and a buyer terminal 120. The seller terminal 122 includes 
a seller processor 123 adapted to generate a seller profile, 
one or more authorized buyer profiles and contract data and 
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to communicate the profiles and contract data to a seller 
interface 133. The seller interface 133 includes a data 
processing device 146 adapted to establish rules for a 
business transaction by submitting a seller profile, one or 
more authorized buyer profiles and contract data (i.e., 
received from the seller processor 123) to a central processor 
140. The seller interface 144 is further adapted for display- 
ing contract data received from the central processor 140, 
and communicating to the seller from the central processor 
140 the acceptance or dispute of contract data by a buyer. 
The central processor 140 electronically organizes a seller's 
contract data using a seller's profile, with the contract data 
and profile being stored in a data storage unit 142. Owner- 
ship and access to the seller's contract data stored in the data 
storage unit 142 is controlled by seller, for example, using 
criterion such as user authorization or password protection. 

[0048] The buyer terminal 120 includes a buyer processor 
124 adapted for generating a buyer profile and communi- 
cating the generated profile to a data processing device 134 
at a buyer interface 132. The buyer interface 132 is adapted 
for displaying contract data received from the central pro- 
cessor 140 and the data processing device 134 communi- 
cates the acceptance or dispute of contract data as input at 
the buyer interface 132 to the central processor. The central 
processor 140 is coupled to a collaborative contracts man- 
ager 110 that provides an interface for buyer and seller 
transaction management including pricing management. The 
central processor 140 processes and stores pertinent business 
transaction information in the data storage unit 142, with 
access thereto beine restricted to authorized users (\ e., 
authorized buyers and sellers via buyer and seller terminals). 
Using the buyer and seller profiles, the collaborative con- 
tracts manager 110 automatically sets prices for transactions 
between the buyer and seller. 

[0049] In a more particular implementation, the central 
processor 140 interfaces with a payment system 141 includ- 
ing an issuing institution 144 and a paying institution 152. 
An issuing processor 145 of the issuing institution 144 
maintains a credit account for the buyer terminal 120 and 
debits a particular buyer terminal's account for transactions 
managed with the communications system 100, such as the 
shipment cost of a product, the product cost and others. In 
response to transactions managed at the central processor 
140, a paying processor 154 of the paying institution 152 
tenders payment to the seller terminal 122, for example, 
when the receipt of goods is acknowledged by a buyer or at 
the time a buyer makes a purchase. 

[0050] FIG. 2 illustrates one approach for implementing a 
collaborative contracts manager (CCM) 210, which provides 
an interface for a buyer system 220 and a seller system 222 
for transaction management, according to another example 
embodiment of the present invention. The CCM 210 
addresses synchronization issues between the buyer system 
220 and the seller system 222, such as those discussed 
above, by implementing pricing rules that have previously 
been agreed upon such that disputes over transaction price 
are typically eliminated. These pricing rules may include, 
for example, criterion defining pricing data that can be 
automatically approved (e.g., offerings within a selected 
buyer variance), and also control pricing information made 
available to different users of the CCM 210. The pricing 
rules may also include, for example, prices associated with 
a particular quantity of products, with different per-product 



prices being assigned for particular quantities of products 
(e.g., such as with a volume discount). In addition, the CCM 
210 may be located geographically remote from both of the 
buyer and seller systems 220 and 222, such that buyer access 
to the CCM does not require access to either the buyer's own 
systems or seller systems and seller access to the CCM does 
not require access to either the seller's own systems or buyer 
systems. This structure eliminates security concerns for both 
parties relative to either party granting the other party access 
to the first party's systems. 

[0051] A contract management system 215 of the seller 
system 222 loads contract data into the CCM 210. A seller 
fulfillment system 260 manages customer orders and inven- 
tory, fulfills orders, and provides invoices for the goods 
provided. The seller fulfillment system 260 communicates 
with the CCM 210 for access to contract and other data (e.g., 
using a network computer link). In one implementation, the 
CCM 210 tracks order fulfillment for showing the percent- 
age of an order quantity that has been fulfilled. 
[0052] A buyer procurement system 270 is programmed 
for reviewing contract data, generating orders, and auditing 
invoice price to order price. The buyer procurement system 
270 also communicates with the CCM 210 for access to 
contract and other data, such as product catalogue data 
maintained by the seller system 222. The CCM 210 main- 
tains the most current contract data, which has been found 
useful in reducing or even eliminating any misunderstanding 
of contract data by either or both the buyer system 220 and 
seller system 222. 

[0053] In a more particular implementation, the CCM 210 
is further adapted to search for contracts for a particular item 
offered by different sellers and to identify prices for purchase 
of the item by a particular buyer. For instance, when a buyer 
requests a particular product at the best price from the CCM 
210, a search is performed using the buyer's information and 
seller information to identify eligible contracts (e.g., the 
seller and buyer meet each other's criteria for establishing a 
contract). Once eligible contracts are identified and pricing 
for execution of the contracts for the particular item (and 
other transaction information, such as quantity and delivery 
options) have been determined, a contract with the lowest 
price is selected and implemented. With this approach, a 
buyer can automatically have a lowest-price eligible contract 
identified and implemented for purchasing products. 

[0054] The buyer and seller systems 220 and 222 may, for 
example, communicate with the CCM 210 and/or each other 
using a communications link, such as the Internet. Each of 
the buyer and seller systems and the CCM 210 include a 
communications port for facilitating these communications. 
For instance, when the communications are over the Inter- 
net, the communications port includes an Internet-protocol 
interface, for communications over links such as a telephone 
line, DSL line, cable line or wireless link. 

[0055] In another implementation, the CCM 210 is con- 
figured to return one of three conditions: 1) no contract is 
found naming a requested buyer, seller and product combi- 
nation, 2) no contract is found with a currently valid price for 
the requested buyer, seller and product combination and 3) 
a contract is found with a currently valid price for the 
requested buyer, seller, product combination and requested 
quantity. With situations 1 and 2, the CCM 210 generates a 
transaction audit exception (e.g., through processes dis- 
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cussed below in connection with FIGS. 3A and 3B). Either 
the buyer or seller can access the CCM 210 to resolve the 
exception in situations 1 and 2, after which the CCM can be 
accessed to execute the contract consistent with situation 3. 

[0056] The approaches shown in the remaining figures 
may, for example, be implemented in connection with the 
collaborative contracts managers and other arrangements 
shown in FIGS. 1 and 2 and discussed above in connection 
therewith. In this regard, reference is made to portions of the 
figures discussed above by way of example in the following 
discussion. 

[0057] FIG. 3A is a flowchart illustrating an example 
approach for automated transaction management with a 
collaborative contracts manager, according to another 
example embodiment of the present invention. At block 300, 
security parameters managing the access of buyer and seller 
terminals (with corporate and/or individual users) to shared 
contract data are managed using security infrastructure in 
the collaborative contracts manager. In this instance, the 
collaborative contracts manager (CCM) may, for example, 
include the CCM 110 of FIG. 1 or a combination of the 
CCM 110 and the central processor 140. A unique user ID 
and password is issued to each individual user (i.e., an 
individual person) authorized by a buyer entity (i.e., an 
individual business, a business division, or a buying group) 
for accessing the CCM. Similarly, a unique user ID and 
password is issued to each individual user authorized by a 
seller entity (i.e., an individual business, a business division 
or a distributor) for accessing the CCM. 

[0058] At block 310, the buyers and sellers submit profiles 
to the CCM using buyer and seller terminals (e.g., buyer and 
seller terminals 120 and 122 of FIG. 1, respectively). The 
CCM is programmed for establishing different profiles for a 
variety of users, such as buyers, sellers, contract owners, and 
contract participants. At block 320, the seller terminal sub- 
mits contract data that can be formalized by a legal docu- 
ment or simply represent a unique set of prices for a specific 
customer (e.g., buyer or buyer group) or set of customers. 
The seller terminal may, for example, be adapted for defin- 
ing whether it is only a particular named participant (e.g., 
buyer organizational element) that can access the contract, 
or the named participant and any organizational element 
reporting into that named participant. Non-contract data and 
quoted sell prices by customer and product can also be 
submitted. A seller terminal can be used to submit public or 
private contracts, with public contracts being available to a 
buyer organization, for example, self -identified as meeting 
the target criteria, and private contracts being selectively 
available to seller-defined buyer groups, for example, that 
meet the target audience criteria. In one implementation, the 
buyer/seller must belong to a purchasing organization that is 
eligible for a particular contract in order to execute trans- 
actions using the contract terms (e.g., to take advantage of 
pricing arrangements for members of the purchasing orga- 
nization). 

[0059] At block 330, upon receipt of contract information, 
the collaborative contracts manager 110 stores contract data 
in its database. After a contract or contracts have been 
recorded, the CCM invokes the buyer's business rules to 
determine if the contract is to be automatically accepted. If 
this is the case, the CCM records the contract as approved 
for use in pricing. If the buyer's business rules require 



manual pricing, the CCM communicates the existence of 
contracts needing review to the buyer and authorizes the 
buyer terminal (e.g., upon submission of an acceptable user 
ID, password, etc., by a user at the buyer terminal) to view 
and approve selected contracts according to the buyer's 
profile at block 340. Once approved, future transactions that 
are governed by the contract are automatically priced using 
the CCM. 

[0060] As discussed above, in order for a buyer to execute 
transactions using a particular contract requiring authoriza- 
tion, the buyer must be authorized to do so (e.g., belong to 
a purchasing organization that is eligible for the contract or 
have negotiated the contract directly). Furthermore, the 
particular user at the buyer terminal must have the opera- 
tional right as defined within operational roles to approve 
contracts, for example, using an authorization level set by a 
buyer organization. 

[0061] Inputs received through the buyer terminal are used 
to select a contract for viewing and approving contract terms 
at block 350. In one instance, the buyer terminal and the 
CCM are adapted for implementing a find, or search, func- 
tion for communicating available contracts to a user at the 
buyer terminal. For instance, a user at the buyer terminal can 
launch a find function to generate a list of contracts through 
a user interface at the buyer terminal. The CCM communi- 
cates with the buyer terminal for communicating (e.g., 
displaying) a list of one or more contracts that satisfy search 
criteria input at the buyer terminal. A user at the buyer 
terminal can then select a contract for viewing from the 
results of the search. 

[0062] Users at the buyer terminal can accept or dispute 
contract term(s) for a selected contract at block 360. In one 
implementation, sellers can update contracts or establish 
new contracts with prospective buyers being responsible for 
reviewing and accepting or disputing new or updated con- 
tract terms (e.g., sell prices). In some implementations, 
buyers are automatically notified of new or updated contract 
terms (e.g., by signing up for a notification email). If 
contract term(s) are not in dispute at block 360, then the 
contract term(s) are accepted, the identity of the approver 
and the date/time of approval are captured and stored with 
the contract and the contract is activated for use at block 370. 
The buyer and seller may then apply these prices to indi- 
vidual invoices and orders processed after the contract has 
been accepted. If contract term(s) are disputed, the CCM 
stores contract term(s) as disputed at block 362 as well as the 
date/time the dispute was notified and the identity of the 
party initiating the dispute. In addition, the buyer user can 
enter notes in the CCM indicating the buyer user's rationale 
for disputing the contract term. These notes become an 
indelible part of the contract terms stored in the CCM. The 
CCM identifies the disputed contract term(s) to the particu- 
lar buyer and seller involved in the dispute at block 366 and 
flags the disputed contract term(s) for review. 

[0063] In the event a seller decides to respond to the 
dispute, the seller submits a response at block 368. Such a 
response may, for example, include sending a contract term 
update to the CCM, entering notes in the CCM indicating 
where the buyer's reasoning is flawed, said notes becoming 
an indelible part of the contract terms stored in the CCM, or 
by making changes through the CCM. A variety of contract 
terms can be updated, such as contract eligibility, product 
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availability, product price, price effective dates and tier 
eligibility. In the event the seller chooses not to acquiesce to 
buyer disputes and the buyer does not approve the contract 
after the dispute is stored at block 362 and the buyer and 
seller are notified at block 366, contract activation does not 
occur, as shown at block 364. Access to the CCM for 
inputting seller responses to disputed terms is controlled 
witha user authorization approach, such as discussed above. 
A user at the buyer terminal may then select an updated 
contract for viewing and approving contract terms at block 
350, with the process resuming from there. 

[0064] FIG. 3B is a flowchart illustrating an example 
automated transaction management approach utilizing a 
collaborative contracts manager (CCM), according to 
another example embodiment of the present invention. FIG. 
3B may be implemented, for example, in connection with 
buyer review and approval of new contracts and subsequent 
review and approval of existing contracts and/or proposed 
contract terms that a buyer initially disputes but later 

[0065] FIG. 3B begins at block 380 with a user at a buyer 
terminal selecting a contract for viewing and approving 
contract term(s). At block 382, the user enters inputs at the 
buyer terminal for accepting or disputing contract term(s) 
for the selected contract. If contract term(s) are accepted at 
the buyer terminal, the updated contract terms are stored as 
accepted at block 384, the CCM notifies the buyer and seller 
of the accepted terms at block 386. A contract is then 
activated within the CCM at block 388, where it used to set 
transaction terms such as pricing for transactions between 
the buyer and seller. The contract remains activated unless 
the buyer and/or seller decide to change and/or dispute terms 
(and, in the condition that certain terms can be changed 
within limits without changing the accepted status of the 
contract, the contract remains activated if these changes are 
effected within the limits). 

[0066] If contract term(s) are disputed at the buyer termi- 
nal (e.g., a buyer inputs disputed and/or alternate terms at 
block 382), the CCM stores the updated contract term(s) as 
disputed at block 392. The buyer and seller are both notified 
of the disputed terms at block 394. The disputed contract 
term(s) are stored as an inactivated contract within the CCM 
at block 396, where it remains inactivated unless the buyer 
decides to accept the previously disputed terms at block 398 
(i.e., requests a change in the contract at a later date). If the 
buyer accepts the previously disputed contract term(s) at 
block 398, the CCM stores the updated contract term(s) as 
accepted at block 384, where the process continues as 
discussed above. If the buyer does not accept the previously 
disputed contract term(s) at block 398, the contract term(s) 
remain as inactivated at block 396. The CCM then can 
process the disputed contract term(s) in one or more of a 
variety of approaches. For example, by deleting the infor- 
mation regarding disputed terms or maintairring the disputed 
terms for a pre-selected time during which the buyer may 
acquiesce. 

[0067] FIG. 4A is a flowchart illustrating an example 
approach for automated contract performance after a con- 
tract has been formed utilizing a collaborative contracts 
manager (CCM), according to another example embodiment 
of the present invention. FIG. 4A begins at block 452 with 
a CCM storing and activating contract terms previously 



agreed upon by a buyer and a seller (e.g., using buyer and 
seller terminals as discussed above). If the seller submits a 
contract update at block 454, the buyer is notified of the 
contract update at block 456. The buyer reviews the updated 
contract at block 450 and, if an acceptable and valid contract 
is found at block 460, the updated contract is stored and 
activated at block 452. For instance, a valid contract includ- 
ing a currently valid price for the particular buyer, seller, 
product combination and requested quantity is found at 
block 460, the contract is stored and activated at block 452. 
If a valid contract is not found at block 460 (e.g., no contract 
is found naming the requested buyer, seller and product 
combination, or with a currently valid price for the requested 
buyer, seller and product combination), the CCM stores the 
updated contract terms as having a contract exception. If the 
seller does not submit a contract update at block 454, the 
current (accepted and activated) contract is used for buyer 
purchases. 

[0068] Once the contract is stored and activated at block 
452, and in the absence of any contract update by the seller 
at block 454, the stored contract is ready for use. At block 
458, a buyer submits a request for performance of the stored 
contract, for example, using a purchase order. At block 470, 
the CCM examines buyer and seller business rules for 
performance details of the purchase in connection with the 
request for performance. The business rules may, for 
example, include buyer and seller profile information, such 
as information relating to acceptable variances in contact 
terms that can automatically be approved. For general infor- 
mation reganW transactions anH for specific information 
regarding profile approaches that may be implemented in 
connection with these and other example embodiments, 
reference may be made to the above -discussed patent 
entitled "Shipment Transaction System and an Arrangement 
Thereof to Hahn-Carlson. For instance, pricing, shipping 
and other contract terms can be verified and/or modified 
using these approaches. In one implementation, the business 
rules are processed at block 470 using a business rules 
processor that is either part of or separate from the CCM. If 
the request for performance falls within prescribed terms of 
the stored contract, there is no contract exceptions) (e.g., an 
expired contract or a performance dispute such as a different 
price or shorter performance date) at block 472 and the 
buyer and seller perform under the contract at block 494. 

[0069] If there is a contract exception at block 472 and the 
business rules can resolve the contract exception at block 
473, the contract terms are resolved and updated at block 
490. For example, if the seller's and/or buyer's business 
rules tolerate flexibility in the performance, these tolerances 
are used to automatically adjust the terms of the contract for 
the particular performance requested at block 458. The 
buyer and seller then perform under the contract using the 
contract terms updated in response to the performance 
dispute. If the business rules cannot resolve the exception at 
block 473 (e.g., if the buyer requests a lesser price than the 
seller will provide and the buyer's business rules do not 
allow for flexibility in the price), the contract term(s) are 
stored as having an exception at block 462. 
[0070] FIG. 4B is a flowchart illustrating an approach for 
programming a collaborative contracts manager (CCM), 
according to another example embodiment of the present 
invention. Once programmed, the CCM is adapted for 
managing transactions, such as by deriving or otherwise 
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providing pricing therefor. Buyer and Seller profiles are used 
to define business rules for the CCM. For one implementa- 
tion of the CCM at block 474, the buyer and/or seller may 
input business rules for automated contract performance 
(e.g., using buyer and seller terminals as discussed above). 
Price business rules, for example, may be selected by the 
buyer and seller as none (no rules), pricing (fixed or tiered 
price), or pricing validation (validation per rules). If no price 
business rules are input at block 474, then no price business 
rules are applied at block 476 and the CCM is not used for 
establishing pricing for contract performance. These pricing 
business rules are implemented when a contract has been 
stored and activated within the CCM. 

[0071] In some implementations, a variety of other busi- 
ness rules are also implemented in connection with the 
example embodiments discussed in connection with FIG. 
4B. In one instance, the total purchases from a particular 
buyer or group of buyers during the term of the contract may 
be limited to not exceed a selected amount; once the selected 
amount has been reached, purchases under the contract are 
not allowed. In another instance, the total purchase of items 
on a given line item within a contract is limited not to exceed 
a selected number of units of quantity (or amount in price) 
in which the contract will be executed. In another instance, 
the contract is limited by timing rules, such as the effective 
date (e.g., at both contract and line item level) of the 
contract, the expiration date (e.g., at both contract and line 
item level) of the contract, as well as the type of date that 
drives the effective and expiration dates (e.g., the order date, 
invoice rM«> ind/or rece''^* A "*<s). 

[0072] If price business rules are input at block 474, then 
the buyer and seller can select pricing or pricing validation 
business rules at block 478. If the buyer and seller do not 
select pricing validation rules at block 478, then pricing 
rules are applied at block 480. When a buyer placing an 
order selects pricing rules, the CCM uses contracts and 
product price information to apply prices to each item on the 
order at block 480. When a seller selects pricing rules, the 
CCM uses contracts and product price information to apply 
prices to each item being sold as part of a particular contract. 

[0073] If pricing validation rules are selected at block 478, 
then pricing validation business rules are applied at block 
482. In this case, stored prices are used by the CCM to 
validate, for example, the price provided from a buyer's 
procurement system and/or a seller's fulfillment system 
(e.g., buyer procurement system 270 and seller fulfillment 
system 260 of FIG. 2) at block 482. The price that is 
provided by the procurement and/or fulfillment system is the 
price used in reconciling order and invoice prices, when 
validated. In this regard, the CCM uses contract and product 
price data to audit the order price against the contract or list 
prices at block 482. If price validation is selected by the 
buyer, the CCM will use contracts and product price infor- 
mation to audit the order price against contract or list prices. 
If price validation is selected by the seller, the CCM will use 
contracts and product price information to audit the invoice 
price against contract or list prices. 

[0074] For instance, using price validation rules, the buyer 
and seller may establish tolerance values for unit prices at 
block 484. The buyer and/or seller may chose to express the 
tolerance values as a percentage of the fixed price or as a 
fixed amount at block 484. In one implementation, the 



tolerance values are expressed as a percentage of the unit 
price at block 488. In another implementation, the tolerance 
values are expressed as a fixed amount of the unit price at 
block 486. 

[0075] The above approaches discussed in connection 
with FIG. 4B can be implemented in a variety of manners. 
For instance, in one example implementation using pricing 
business rules, the buyer and seller establish that pricing 
business rules will be applied for automated contract per- 
formance. If pricing business have not been applied, the 
CCM does not provide pricing for the transaction (e.g., as 
processed by the central processor 140 of FIG. 1). If 
business rules are selected, the buyer and seller can decide 
whether to use pricing or pricing validation business rules. 
If pricing rules are selected, then the prices automatically set 
by the CCM are the definitive prices used for contract 
performance. 

[0076] In another instance, pricing validation rules are 
selected and prices from the CCM are used to validate prices 
provided by the seller's fulfillment system and/or the buy- 
er's procurement system. The buyer and seller will also 
establish tolerance values expressed as a fixed amount or 
percentage of the unit price. For example, if the buyer and 
seller both have a three percent tolerance value for the unit 
price, pricing validation rules are used to determine whether 
the prices in a particular transaction meet these tolerances. 
For instance, if the unit price stored in the CCM is one 
percent less than the unit price stored in the seller's fulfill- 
ment system and one percent greater than the unit price 
stored in the buyer's procurement system, the difference in 
the unit price of the CCM is within the three percent 
tolerances. The price validation business rules will therefore 
effect automatic approval of the transaction because the 
three-percent tolerance has been met for both the buyer and 
seller. The transaction will proceed using the unit price from 
the CCM if buyer and seller have previously agreed to 
contract performance in this manner. 

[0077] Alternatively, the buyer may have agreed to use the 
unit price stored in the CCM provided that the unit price in 
the buyer's procurement system is within the three percent 
tolerance of the unit price in the CCM. In another alterna- 
tive, the seller may have agreed to use the unit price stored 
in the CCM provided that the unit price in the seller's 
fulfillment system is within the three-percent tolerance of 
the unit price in the CCM. These and other alternatives can 
be readily implemented in connection with the examples 
discussed above and with those shown in FIG. 4B. 

[0078] FIGS. 5A-5D are block diagrams illustrating 
example user profile configuration approaches with relation- 
ships shown between buyers, sellers and organizations for 
use with a collaborative contracts manager (CCM), such as 
discussed above, according to other example embodiments 
of the present invention. A plurality of user profiles are 
supported, including seller (e.g., manufacturer or distribu- 
tor), buyer, contract owner, and member profiles. A seller/ 
buyer profile is arranged so that the seller/buyer for whom 
the profile is established acts as a financial participant in 
contracts established using this approach, and may submit 
contract data as participant and/or as a contract owner. A 
member relationship profile facilitates access to transac- 
tional data, but does not necessarily act to facilitate financial 
participation of the user for whom the profile is established. 
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With these approaches, contract terms such as pricing and 
others can be managed using a CCM. 

[0079] Referring now to FIG. 5A, block 500 represents a 
manufacturer operating as a seller and/or contract owner 
who submits a product list, contract cost, and eligible buyers 
to the CCM. The manufacturer at block 500 views a group 
purchasing organization (GPO) (block 510) as a contract 
participant, an individual buyer (block 520) as a retail buyer 
and a distributor (block 530) as a wholesale buyer. The 
contract approaches for each relationship with the manufac- 
turer 500 are tailored for the particular relationship. For 
instance, if an individual buyer 520 accepts a contract, the 
CCM stores a sell price. If a contract submitted by the 
manufacturer 500 is accepted by a distributor 530, the CCM 
stores a contract cost that is then used for future transactions 
between the distributor and the manufacturer. Similarly, if a 
GPO 510 accepts a contract offered by the manufacturer 
500, the CCM stores the contract for use by members of the 
GPO. 

[0080] The example embodiment shown in FIG. 5B illus- 
trates an example user profile configuration from a distribu- 
tor perspective. A distributor at block 532 has profile infor- 
mation including seller and/or contract owner information 
that is stored at the CCM. The distributor 532 views rela- 
tionships with a manufacturer at block 502 as a wholesale 
seller relationship, with a GPO at block 512 as a contract 
participant relationship and with an individual buyer at 
biuck 522 as a retail uujvi relationship. Price relatiouiui^i 
between the distributor 532 and the manufacturer 502, GPO 
512 and buyer 522 are stored at the CCM. 

[0081] FIG. 5C illustrates an example user profile con- 
figuration from a buyer perspective at block 524. The buyer 
524 has profile information including buyer and/or mem- 
bership profile information that is stored at the CCM. The 
buyer 524 views relationships with both a manufacturer at 
block 504 and a distributor at block 534 as retail seller 
relationships (i.e., when the manufacturer sells directly to 
retail buyers). The relationship between the buyer 524 and a 
GPO at block 514 is a membership relationship, with the 
buyer being able to use contract terms assigned to the GPO 
and stored at the CCM. 

[0082] FIG. 5D illustrates an example user profile con- 
figuration from a GPO perspective at block 516. The GPO 
516 views relationships with both a manufacturer at block 
506 and a distributor at block 536 as a contract participant 
relationship, with the GPO participating in contracts stored 
at the CCM in connection therewith. The GPO 516 views a 
relationship with a buyer at block 526 as a member rela- 
tionship, with information regarding the membership of the 
buyer stored at the CCM, and the buyer correspondingly 
able to participate in contracts for the GPO 516 also stored 
at the CCM. 

[0083] While certain aspects of the present invention have 
been described with reference to several particular example 
embodiments, those skilled in the art will recognize that 
many changes may be made thereto without departing from 
the spirit and scope of the present invention, aspects of 
which are set forth in the following claims. 



What is claimed is: 

1. An automated pricing system for use by a buyer and 
seller who provide business rules for use by the automated 
pricing system, the automated pricing system comprising: 

a computer and communications node adapted to receive 
and use the business rules to derive a specific term for 
a transaction to be implemented by the buyer and seller, 
the transaction having a price that is set as a function of 
the specific term. 

2. The system of claim 1, wherein the computer and 
communications node is adapted to derive a specific term 
that includes a price term. 

3. The system of claim 1, wherein the computer and 
communications node is adapted to store the business rules. 

4. The system of claim 1, wherein the computer and 
communications node is adapted to retrieve the business 
rules from a node remote from the computer and commu- 
nications node. 

5. The system of claim 1, wherein the computer and 
communications node is adapted to receive proposed prod- 
uct-pricing data from a seller and to provide the product- 
pricing data to potential buyers and, upon acceptance by a 
potential buyer, storing the product-pricing data, and 
wherein the computer and communications node is further 
adapted to use the stored product-pricing data to set the price 
of a transaction to be implemented between said potential 
buyer and seller. 

6. The system of claim 1, wherein the computer and 
communications node is adapted to receive business rules 
froi^ buyer and s*Ii,.- via data entry terminals remote 
from the computer and communications node. 

7. The system of claim 6, further comprising at least one 
of the data entry terminals. 

8. The system of claim 6, wherein the computer and 
communications node is programmed to control access to 
the computer and communications node for transmitting the 
business rules from the data entry terminals. 

9. The system of claim 1, wherein the computer and 
communications node is further adapted to match a product 
identification term from the buyer with a seller product for 
identifying a particular product for which the specific term 
is derived. 

10. The system of claim 9, wherein the computer and 
communications node is adapted to assign a buyer identifi- 
cation term to a particular seller product in response to an 
input from at least one of the buyer and the seller. 

11. The system of claim 1, wherein the computer and 
communications node includes a pricing engine pro- 
grammed to use business rules and transaction information 
to derive a pricing term for a transaction, the transaction 
information including at least one of: a contract identifier for 
the transaction, an item identifier for an item being sold, 
quantity and order date. 

12. The system of claim 11, wherein the pricing engine is 
adapted to identify transaction prices to a buyer for a 
selected transaction between the buyer and at least two 
sellers. 

13. The system of claim 12, wherein the pricing engine is 
adapted to automatically select and execute a lowest-price 
transaction between the buyer and one of the sellers for 
which the selected transaction is the lowest price, relative to 
the selected transaction between the buyer and the others of 
the at least two sellers. 
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14. The system of claim 11, wherein the pricing engine is 
adapted to identify prices for a particular transaction 
between the buyer and a plurality of sellers and to inform the 
buyer of the prices. 

15. The system of claim 1, wherein the business rules 
include compliance information that must be met before 
making the transaction payable, wherein the computer and 
communications node is further adapted to use the compli- 
ance information to authorize payment for the transaction. 

16. The system of claim 15, wherein the compliance 
information includes at least one of: notice of delivery of 
goods, notice of receipt of goods, notice of acceptance of 
goods, receipt of customs clearance and payment of customs 
fees. 

17. An automated transaction system comprising: 

a buyer terminal configured and arranged to interface with 
a buyer, display seller offerings and receive and trans- 
mit buyer contract information from the buyer; 

a seller terminal configured and arranged to interface with 
a seller, display at least some of the seller offerings and 
receive and transmit seller contract information from 
the seller; and 

a centrally-accessible computer and communications 
node adapted to communicate with the buyer terminal 
and the seller terminal and to provide a common source 
of data for users of the buyer terminal and users of the 
seller terminal, the data including characteristics and 
pricing of the seller offerings, and further adapted to 
autoinaucair, uerive rules uy which purchases of uie 
seller offerings are made in response to contract infor- 
mation including transaction pricing information from 
at least one of the buyer and the seller. 

18. The automated transaction system of claim 17, 
wherein the centrally-accessible computer and communica- 
tions node is further adapted to automatically characterize 
and modify rules by which purchases of the seller offerings 
are made using nested contracts involving a manufacturer's 
contract with a buying organization that specifies a base sell 
price for an item and a buyer's contract with the buying 
organization for said item. 

19. The automated transaction system of claim 18, 
wherein the centrally-accessible computer and communica- 
tions node is configured and arranged to use the nested 
contracts and the base sell price to establish a seller offering 
for display at the buyer terminal. 

20. The automated transaction system of claim 19, 
wherein the centrally-accessible computer and communica- 
tions node is further adapted to add a markup to seller 
offerings available through a buying organization and to 
directly quote a final sell price to potential buyers, using the 
nested contracts, the base sell price and the markup. 

21. The automated transaction system of claim 17, 
wherein the centrally-accessible computer and communica- 
tions node is further adapted to input, access, maintain, and 
manage rules determining conditions for user interaction 
with the system. 

22. The automated transaction system of claim 21, 
wherein the centrally-accessible computer and communica- 
tions node is further adapted to input, access, maintain, and 
manage buyer rules including at least one of: buyer rules for 
determining conditions for user interaction with the system; 
seller rules for determining conditions for user interaction 



with the system and seller offering information for deter- 
mining a unit cost of seller offerings. 

23. The automated transaction system of claim 17, 
wherein the centrally-accessible computer and communica- 
tions node is further adapted to store at least one criterion 
defining ownership of data and access to data and, using the 
at least one criterion, control information made available to 
a user via the centrally-accessible computer and communi- 
cations node. 

24. The automated transaction system of claim 17, 
wherein the centrally-accessible computer and communica- 
tions node is further adapted to store at least one criterion 
defining what pricing data can be approved by the system 
without human interaction and, using the at least one crite- 
rion, control information made available to a user via the 
centrally-accessible computer and communications node. 

25. The automated transaction system of claim 17, 
wherein the centrally-accessible computer and communica- 
tions node is further configured and arranged for cross- 
referencing different identification numbers from a plurality 
of sources, the different identification numbers correspond- 
ing to a single product. 

26. The automated transaction system of claim 25, 
wherein the centrally-accessible computer and communica- 
tions node is further configured and arranged to use the 
cross-referenced identification numbers to identify charac- 
teristics of a single product. 

27. The automated transaction system of claim 17, 
wherein the centrally-accessible computer and communica- 
tions node is further configured and arranged to store the 
buyer and seller profile information and to use the stored 
profile information to automatically negotiate contract terms 
in response to a request for change in terms input via at least 
one of the buyer and seller terminals. 

28. The automated transaction system of claim 27, 
wherein the centrally-accessible computer and communica- 
tions node is configured and arranged to use the profile 
information to automatically negotiate payment terms of the 
seller offerings in response to a buyer-input request for a 
change in payment terms. 

29. The automated transaction system of claim 27, 
wherein the centrally-accessible computer and communica- 
tions node is configured and arranged to use the profile 
information to automatically negotiate shipping terms of the 
seller offerings in response to a buyer-input request for a 
change in shipping terms. 

30. The automated transaction system of claim 17, 
wherein the centrally-accessible computer and communica- 
tions node is further configured and arranged to receive 
updated seller offering characteristics from the seller termi- 
nal and, in response, to send a notification to the buyer 
terminal of the updated seller offering characteristics. 

31. The automated transaction system of claim 30, 
wherein the centrally-accessible computer and communica- 
tions node is further configured and arranged to receive an 
acceptance notification of the updated seller offering from 
the buyer terminal and, in response, to update the rules by 
which purchases of the sellers offerings are made. 

32. The automated transaction system of claim 31, 
wherein the centrally-accessible computer and communica- 
tions node includes a database configured and arranged to 
store seller offering characteristics and wherein the cen- 
trally-accessible computer and communications node is fur- 
ther configured and arranged to update the database to 
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include new seller offering characteristics corresponding to 
the updated seller offering characteristic. 

33. The automated transaction system of claim 17, 
wherein the centrally-accessible computer and communica- 
tions node is adapted to store product identifiers with 
associated sell prices input via the seller terminal and to use 
the stored product identifiers and associated sell prices to 
automatically form a contract in response to a buyer pur- 
chase request for product corresponding to the stored prod- 
uct identifiers and at the stored associated sell price for the 
product identifier. 

34. The automated transaction system of claim 33, 
wherein the centrally-accessible computer and communica- 
tions node is adapted to store sell prices for selected quantity 
ranges of product corresponding to the stored product iden- 
tifiers, and in response to receiving a request from the buyer 
terminal for a particular quantity of product, to automati- 
cally execute a contract for purchase of the product at the 
stored sell price for the selected quantity range in which the 
particular product quantity falls. 

35. The automated transaction system of claim 17, 
wherein the centrally-accessible computer and communica- 
tions node is configured and arranged to search for and 
identify contracts meeting search criteria submitted from at 
least one of the buyer and seller terminals and to report the 
identified contracts to the at least one of the buyer and seller 
terminals submitting the search criteria. 

36. The automated transaction system of claim 17, 
wherein the centrally-accessible computer and communica- 
tions node includes a database configured and arranged to 
store product information and to cause the catalog informa- 
tion to be displayed at the buyer terminal. 

37. The automated transaction system of claim 36, 
wherein the centrally-accessible computer and communica- 
tions node is further configured and arranged to use buyer 
configuration information specific to a selected buyer at the 
buyer terminal and to configure the displayed catalog infor- 
mation for the selected buyer. 

38. The automated transaction system of claim 17, 
wherein the centrally-accessible computer and communica- 
tions node is adapted to track order fulfillment characteris- 
tics. 

39. The automated transaction system of claim 38, 
wherein the centrally-accessible computer and communica- 
tions node is adapted to track the percentage of an order 
quantity that has been fulfilled. 

40. A centrally-accessible computer and communications 
node configured and arranged to: 

communicate with a plurality of buyer terminals and 
seller terminals and to provide a common source of 
data for users of the terminals, the data including seller 
offerings; 

control access to the data and for configuring the type and 
arrangement of the data to be communicated with the at 
least one buyer terminal in response to the identifica- 
tion of a buyer receiving the communications; and 

for a transaction to be implemented by a buyer for the 
seller offerings, use business rules for the buyer and 
sellers to automatically derive a price term for the 
transaction. 

41. The centrally-accessible computer and communica- 
tions node of claim 40, further comprising: 



at least one computer configured and arranged for access- 
ing data from the common source for communicating 
the data; and 

at least one communications port configured and arranged 
for transmitting signals with at least one of the termi- 
nals. 

42. The centrally-accessible computer and communica- 
tions node of claim 41, further comprising identification 
means configured and arranged for identifying a buyer at a 
buyer terminal for configuring the type and arrangement of 
the data to be communicated to the buyer. 

43. The centrally-accessible computer and communica- 
tions node of claim 42, wherein the identification means 
includes a computer programmed to identify a buyer in 
response to an identification input. 

44. The centrally-accessible computer and communica- 
tions node of claim 42, wherein the computer is programmed 
to communicate seller offerings to buyers in response to the 
identification of the buyer. 

45. The centrally-accessible computer and communica- 
tions node of claim 44, wherein the computer is programmed 
to communicate seller offerings of the same product to 
different buyers, the communicated offerings having terms 
and conditions that are selected in response to the identifi- 
cation of each buyer. 

46. The centrally-accessible computer and communica- 
tions node of claim 44, wherein the computer is programmed 
to communicate similar offerings from different sellers using 
similar terms and conditions to a buyer in response to the 
buyer's identification. 

47. The centrally-accessible computer and communica- 
tions node of claim 46, wherein the computer is programmed 
to communicate the similar offerings using similar terms in 
response to the sellers selecting offering parameters indicat- 
ing that the buyer should receive similar terms and condi- 
tions for the similar offerings from each of the sellers. 

48. The centrally-accessible computer and communica- 
tions node of claim 41, further comprising: 

a data storage arrangement configured and arranged to 
store data for at least one user at one of the terminals, 
wherein the computer is further configured and 
arranged to communicate the stored information with 
the terminals via the communications port. 

49. The centrally-accessible computer and communica- 
tions node of claim 48, wherein the computer is programmed 
to restrict access to the stored data based upon a set of access 
characteristics defined at least by said at least one user 
owning the data. 

50. The centrally-accessible computer and communica- 
tions node of claim 41, wherein at least one buyer and at 
least one seller use different product identification codes for 
the same product and wherein the computer is programmed 
to match the product identification code of the at least one 
buyer with a product identification code of the at least one 
seller. 

51. The centrally-accessible computer and communica- 
tions node of claim 41, wherein the computer is programmed 
to store and update invoice information for at least one of the 
users in response to a transaction. 

52. The centrally-accessible computer and communica- 
tions node of claim 41, wherein the computer is programmed 
to store and update invoice information in response to at 
least one of: an order from a buyer, receipt of an order by a 
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seller, shipment by a seller, receipt by a buyer, rejection by 
a buyer and payment from a buyer. 

53. The centrally-accessible computer and communica- 
tions node of claim 51, wherein the computer is programmed 
to automatically effect payment to the seller for the trans- 
action. 

54. The centrally-accessible computer and communica- 
tions node of claim 53, wherein the computer is programmed 
to invoice the buyer for the transaction. 

55. The centrally-accessible computer and communica- 
tions node of claim 53, wherein the computer is programmed 
to automatically effect payment to the seller from a third 
party credit source authorized to pay the seller on behalf of 
the buyer. 

56. The centrally-accessible computer and communica- 
tions node of claim 41, wherein the computer is programmed 
to suspend an offering in response to a user input changing 
terms of the offering. 

57. The centrally-accessible computer and communica- 
tions node of claim 41, wherein the computer includes a 
plurality of computers. 

58. An automated pricing system for use by a buyer and 
seller who provide business rules, the automated pricing 

means for providing business rules for pricing a transac- 
tion to be implemented by the buyer and seller; and 

means for receiving and using the business rules to derive 
a specific term for the transaction, the transaction 
having a price that is set as a function of the specific 

59. A method for automated pricing of transactions 
between a buyer and seller who provide business rules, the 
method comprising: 

providing business rules for pricing a transaction to be 
implemented by the buyer and seller; and 

receiving and using the business rules to derive a specific 
term for the transaction, the transaction having a price 
that is set as a function of the specific term. 

60. A method for transaction management in a system 
including a centrally accessible computer and communica- 
tions node, the method comprising: 

interfacing with the centrally-accessible computer and 
communications node via a seller terminal and display- 
ing at least one seller offering at the seller terminal; 

interfacing with the centrally-accessible computer and 
communications node via a buyer terminal and display- 
ing at least one seller offering at the buyer terminal; 



communicating data from the centrally-accessible com- 
puter and communications node to the buyer terminal 
and the seller terminal, and characterizing and modi- 
fying rules by which purchases of the at least one seller 
offering is made at the centrally-accessible computer 
and communications node; and 

using the characterized and modified rules, deriving a 
specific term for a transaction to be implemented by a 
particular buyer and at least one particular seller, the 
transaction having a price that is set as a function of the 
specific term. 

61. The method of claim 60, wherein characterizing and 
modifying rules includes programming the centrally-acces- 
sible computer and communications node to automatically 
characterize and modify rules by which purchases of the at 
least one seller offering is made. 

62. The method of claim 60, wherein deriving a specific 
term includes deriving a price variance term, further com- 
prising: 

comparing an offer for a seller offering made by the 
particular buyer to determine compliance between the 
offer and a price of the seller offering within the price 
variance term; and 

in response to determining that the offer received com- 
plies with the contract terms, setting the price for a 
transaction between the buyer and the seller. 

63. The method of claim 60, wherein deriving a specific 
term for a transaction further comprises: 

receiving a request from a buyer for a product having a 
first product identification; 

matching the first product identification to at least one 
other product identification for the same product from 
at least one seller, the product identifications being 
different; and 

deriving a price term for the first product as a function of 
the matching. 

64. The method of claim 60, wherein characterizing and 
modifying rules by which purchases of the at least one seller 
offering is made includes assigning financial credit to at least 
one buyer and wherein deriving a specific term for a 
transaction includes using the financial credit to approve 
business transactions for the at least one buyer. 



Exhibit B 



4 




WENT TRANSACTION 




M ANP AN ARRANGEMENT THEREOF 



Related Patent Documents 

instant application is a continuation-in-part o£tlS. Patent Application 
No. 60/124,124 filed on March 12, 1999 entjtied "Shipment Transaction System 
And An Arrangement Thereof, which is a cprfhnuation-in-part of U. S. Patent 
Application Serial No. 08/748,243, filedlNovember 4, 1996, with the same title 
(USBA.02PA), both of which reincorporated herein by reference. The instant 
application is also related^tfU.S. Patent Application Serial No. 09/259,657, filed 
February 26, 1999^entitled "Shipment Transaction System And Method" 
(USBA.02C^and related to U. S. Patent Application Serial No. 09/310,71 1, filed May 
12, 199^vwitu die same title, both of wliich are continuations of U.S. Patent Application 
ial No. 08/748,243 and are incorporated herein by reference. 



Field of the Invention 

The present invention relates to a computer processing system for shipment 
transactions involving a shipper and a carrier or a vendor and service providers where 
the transaction involves services. 



25 Background of fte Invention 

Processing shipment transactions between a shipper and a carrier has been a 
manually intensive effort and has experienced little change. Generally, the shipment 
transaction process involves a goods transport path and a payment process path. The 
goods transport path typically starts when a carrier picks up the goods at the shipper's 
3 0 warehouse dock. The carrier receives a copy of a transaction document, sometimes 
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referred to as a bill of lading (BOL), from the shipper. This type of transaction 
document includes information associated with the shipment transaction that is used by 
the shipper and carrier to track the shipment of goods. The carrier transports the goods 
to the receiver where the receiver signs a copy of the BOL to verify receipt of the goods. 
After the carrier has delivered the goods to the receiver, the carrier also submits the 
receiver's signed copy of the BOL to the carrier's headquarters. 

At this point, records are generated that contain information about requested 
pick-up and delivery times, origin and destination, and type of load. The first problem 
in the process can occur when the carrier arrives to pick up the load. If the shipment is 
not ready or there are delays at the loading dock, accessorial charges may be imposed 
by the carrier. Because they are not part of the original BOL, the shipper may dispute 
these charges later, and this can cause payment delays down the line. Back at the 
loading dock, a second problem is created when manual changes are made on the BOL. 
Unfortunately, these changes rarely get recorded in the shipper's permanent electronic 
records causing a difference between the shipper's and the carrier's paperwork for the 
same load. 

Now on the road, the driver needs to send the paperwork back to headquarters. 
Because the primary job of the driver is to get the shipment to its destination in a timely 
manner, paperwork can sometimes be delayed, and it may be days before the carrier 
headquarters receives a copy of the BOL. 

The driver reaches the destination and delivers the shipment. At the point of 
delivery, the driver is supposed to provide notification of delivery. Again, this may or 
may not happen. When it does not, vital information is delayed or missing in the supply 
chain. 

When the original and delivery copies of the BOL finally reach the clerk at the 
carrier's offices, the clerk sends out an invoice for the original shipment. A clerk at the 
shipper's office receives the invoice, often amid a pile of invoices for many carriers, and 
attempts to match the invoice with a copy of the original BOL. If a billing error is 
discovered, the clerk might send a check for a partial payment or simply hold the entire 
payment until the corrected invoice is provided. The carrier clerk receives this check 



and must then track down the original BOL and delivery copy to know why the check is 
for less than the total amount due. It is only after communicating wit the shipper 
directly that the carrier finds out a mistake was made in the original paperwork. The 
carrier sends the shipper an amendment to the original invoice, and the shipping clerk 
5 must then organize and file all the paperwork together. 

The payment process path starts when the carrier picks up the goods from the 
' shipper. The carrier sends a copy of the BOL to the carrier's headquarters for 
processing. The carrier headquarters rates the BOL. Rating involves determining the 
shipment cost that takes into the account various shipment parameters such as the size, 
1 0 weight, type of material, and destination of the shipment. The carrier creates an invoice, 
sets up an accounts receivable, and sends the invoice to the shipper's accounts payable 
department. The shipper, either internally or via a third party, audits the invoice to 



'sD ensure the final cost is proper. 

ru One of the more burdensome aspects of the traditional process involves reaching 

•J 15 agreement as to the final cost. If there is a dispute as to final cost, the shipper and 

!;* carrier begin a burdensome and sometimes lengthy negotiation process in an attempt to 

» ■ settle the dispute. If the dispute is resolved, the shipper sets up an accounts payable for 

O 

\jj • the transaction. The shipper will then send payment to the carrier and clear the accounts 



payable. The traditional process for paying the carrier and clearing the accounts payable 



□ 2 0 involves several manually intensive steps. Upon receipt of payment, the carrier clears 

O 

the accounts receivable. The traditional process for clearing an accounts receivable 
includes the carrier manually inputting final payment information into the accounts 
receivable system. 

The traditional approach can lead to many disadvantages for a transaction 

2 5 between one shipper and one carrier. Typically, however, there are multiple carriers and 

shippers involved in multiple transactions, which makes the situation more complex, 
and that much more slow and inefficient. The process is manually intensive in that it 
relies on the hard copy of the BOL for proof of delivery and payment, resulting in a 
series of repetitive and time-consuming steps. Also, each BOL is often rated multiple 

3 0 times by multiple parties creating excessive redundancy. 



3 



Traditional shipment transaction systems are also highly susceptible to billing 
errors and fraud. For example, there is no connection between the delivery of goods and 
when the shipper is billed for delivery. This may result in double billing, no billing at 
all, or over-billing the shipper for freight delivery charges. Also, auditing error may 
occur which results in incorrect billing or payment. In addition, the carrier waits a 
disproportionately long time for payment while the invoice is being audited and/or 
disputed. For example, traditionally, a delivery takes about five days whereas payment 
takes about thirty days. This unnecessary delay adversely affects the carrier's working 
capital resources. 

Additional costs arise as a result of the existing inefficiencies. Many of the costs 
are individually small, but very large in the aggregate. For example, the carrier incurs 
administrative costs including: the cost to create and deliver the initial invoice, costs of 
resolving billing disputes, costs of providing a signed copy of the BOL to the shipper, 
and costs of posting accounts receivable. The shipper incurs similar administrative 
costs. 

Another disadvantage of traditional shipment transaction systems is that they 
have a tendency to strain relationships. Because carriers and shippers do not always 
have an effective way to communicate about the shipment, business partnerships can be 
strained when there are disputes. Continuous inaccuracies in either the shipment or 
invoice process cerate unnecessary tension along the entire supply chain for both 
shippers and carriers. 

An additional disadvantage involves the inability to obtain immediate 
information regarding a shipment. Since the process is largely conducted manually, it is 
very difficult to track a shipment. To learn of the status of shipment or payment, there 
are various manual steps involved. For example, if the shipper wants to know if the 
carrier delivered the goods and if the payment has been made, the shipper must call the 
carrier and the appropriate financial institution. 

There have been numerous attempts to improve the existing shipment and 
payment process. Some improvements have been made to each separate step of 
completing a shipment transaction, but the entire method remains relatively unchanged. 



For example, freight agents are used by shippers to schedule shipments and to process 
the invoice from the carrier. Also, third party service providers have taken over the role 
of managing the shipper's accounts payable department. 

Another attempt to improve this burdensome transaction process involves the 
use of the Internet. Carriers have offered Internet access to their shipment information. 
Shippers access the carrier's Internet address and find out the immediate status of the 
shipment. A disadvantage of this system arises when, as in many applications, the 
shipper is using multiple carriers. In this typical situation, the shipper separately 
accesses the address of each carrier in order to find out the status of each shipment. 
This is unduly time-consuming. 

Another disadvantage of traditional systems is that the shipper's reference 
number and the carrier's reference number are not compatible. The carrier maintains 
the shipment data, so the shipper accesses the data using the carrier's reference number 
rather than the shipper's reference number. The shipper and carrier track each shipment 
using multiple reference numbers. 

These various attempts to improve the overall process have fallen short of 
providing a convenient and cost effective system to process a shipment transaction. 

Summary of the Invention 

The present invention is directed to a shipment transaction system for processing 
transaction information related to goods shipped from a shipper by a carrier. According 
to one example implementation of the present invention, the system includes a 
processor arrangement that maintains shipper credit data for shippers and to process the 
transaction information in response to control data communicatively coupled between 
the processor arrangement and users of at least one type. The processor arrangement is 
linked with various users via a communications channel, and is programmed to receive 
control data from the users, to verify that the received control data is from an authorized 
source, and to evaluate the shipper credit data and the control data. In response, the 
processor arrangement determines whether to generate data that authorizes payment to 
the appropriate carriers). 



According to another example implementation of the present invention, a 
shipment transaction system includes a processor arrangement programmed and 
configured to maintain shipper credit data of said one of a plurality of shippers, to 
process the transaction information in response to control data communicatively 
coupled between the processor arrangement and users of at least one type, and to 
automatically audit shipment transactions between shippers and carriers. The system 
further includes at least one communication channel communicatively linking the 
processor arrangement with the users of said at least one type, with the processor 
arrangement being further programmed to receive control data from the users, to verify 
that the received control data is from an authorized source, and to evaluate the shipper 
credit data and the control data and, in response, to determine whether to generate 
authorization data that authorizes payment to one of a plurality of carriers. 

More specific implementations of one or both of the above systems involving 
the following. The processor arrangement permits authorized ones of the shippers and 
authorized ones of the carriers to review audit discrepancies using .a communication 
channel communicatively coupled with the processor, arrangement. The processor 
arrangement permit authorized ones of the shippers to approve payment to selected ones 
of the carriers without adversely impacting credit data of the authorized shippers, and 
permits authorized ones of the carriers to delay shipment for selected ones of the 
shippers without adversely impacting credit data of the authorized carriers. 

In yet another embodiment, a shipment transaction system includes a processor 
arrangement programmed and configured to maintain shipper credit data of a shipper, to 
process the transaction information in response to control data communicatively 
coupled between the processor arrangement and users of at least one type, and to 
maintain a database of shippers and carriers, the database having a main parameter set 
for validating ones of the shippers and carriers that are qualified as users thereof and 
having respective data sets for the validated shippers and carriers indicating varying 
communication access levels for communicators of each respective validated shipper 
and carrier. At least one communication channel communicatively links the processor 
arrangement with the users of said at least one type, and the processor arrangement is 



audits shipment transactions and reports thereon to at least one of the validated shippers 
and carriers according to one of the varying communication access levels for 
communicators of the validated shipper and/or carrier. 

Another more specific embodiment involve the above shipment transaction 
system with the processor arrangement further programmed and configured to audit 
shipment transactions and report thereon to at least one of the validated shippers and 
carriers according to different communication access levels, each being defined based 
on data provided by a respective one of the validated shippers and carriers. Further, the 
processor arrangement can be configured and arranged to permit and block access to 
shipment transaction information according to information stored in the database, and 
the database can include information defining payment authorization levels for 
communicators, wherein the processor arrangement permits approval for payment to 
carriers for shipment transactions according to the information defining payment 
authorization levels. As enhancements to this implementation, the information defining 
oayment authorization levels for communicators in the database is defined by a 
specified type of user, and the information defining payment authorization levels for 
communicators is downloaded into the database from the user at a remote site. 

According to one application, the present invention is directed to a transaction 
validation system for auditing transaction information related to services provided by 
one of a plurality of vendors and processed by one of a plurality of service providers. 
The system comprises a central processor arrangement programmed and configured to 
maintain data relating to an authorized profile list criterion that includes information 
about authorized users empowered to authorize payment by the vendor, and 
programmed and configured to process the transaction information by determining 
whether the transaction information satisfies the authorized profile list criterion, and 
using the authorized profile list criterion to generate information for auditing a 
transaction between one of a plurality of vendors and one of a plurality of service 
providers. 

According to another application, the present invention is directed to a transaction 
validation system for auditing transaction information related to services provided by a 



vendor and a plurality of subvendors and processed by one of a plurality of subvendor 
controlled service providers. The system comprises a central processor arrangement, 
coupled to vendor and subvendor, programmed and configured to maintain data relating 
to an authorized profile list criterion that includes information about authorized users 
empowered to authorize payment by the vendor, and programmed and configured to 
process the transaction information by determining whether the transaction information 
satisfies the authorized profile list criterion, and using the authorized profile list 
criterion to generate information for auditing a transaction between the vendor and both 
of the plurality of subvendors and plurality of subvendor controlled service providers. 

According to another application, the present invention is directed to a 
transaction validation system for auditing transaction information related to services 
provided by a vendor, the transaction information being generated by one of a plurality 
of service providers prior to processing by the vendor. The system comprises a central 
processor arrangement programmed and configured to maintain data relating to an 
authorized profile list criterion that includes information about authorized users 
empowered to authorize payment by the vendor to service provider, and programmed 
and configured to process the transaction information by determining. whether the 
transaction information satisfies the authorized profile list criterion, and using the 
authorized profile list criterion to generate information for auditing a transaction 
between the vendor and one of a plurality of service providers. 

Other aspects of the present invention are directed to methods for implementing 
the computer operations at a central control center, and to arrangements and methods for 
configuring and operating the coordination of the above-characterized shipment 
transaction system at the shipper's station and with respect to the carrier. 

The above summary of the present invention is not intended to describe each 
illustrated embodiment, or every implementation, of the present invention. This is the 
purpose of the figures and of the detailed description that follows. 



Prjef Descrip tion of the Drawings 



Other aspects and advantages of the invention will become apparent upon 
reading the following detailed description and upon reference to the drawings in which: 

FIG. 1 is a block diagram illustrating a specific embodiment that incorporates 
principles of the present invention; 

FIG. 2 is a block diagram illustrating an example flowchart for programming the 
shipper processor 24 of FIG. 1 according to the present invention; 

FIG. 2a is a block diagram illustrating an example flowchart for programming 
the BOL rating engine 30 of FIG. 1 according to the present invention; 

FIG. 3 is a block diagram illustrating an example flowchart for programming the 
data processing device 34 of FIG. 1 according to the present invention; 

FIG. 4 is a block diagram illustrating an example flowchart for programming the 
central processor 40 of FIG. 1 manipulating the transaction information according to the 
present invention; 

FIG. 5 is a block diagram illustrating an example flowchart for programming the 
issuing processor 45 of FIG. 1 authorizing a transaction according to the present 
invention; 

FIG. 6 is a block diagram illustrating an example flowchart for programming the 
VRU unit 48 according to the present invention; 

FIG. 7 is a block diagram illustrating an example flowchart for programming the 
central processor 40 of FIG. 1 generating a deposit file according to the present 
invention; 

FIG. 8 is a block diagram illustrating an example flowchart for programming the 
paying processor 54 of FIG. 1 according to the present invention; 

FIG. 9 is a block diagram illustrating an example flowchart for programming the 
issuing processor 45 of FIG. 1 crediting a transaction according to the present invention; 

FIGs. 1 OA- 10C are flow diagrams depicting an example operation of 
implementing ship transaction using the data processing flow addressed herein, 
according another aspect of the present invention; 



FIG. 1 1 illustrates a communication path from an architectural perspective in 
which an array of computers and data routers are used in an example implementation of 
a system and method, according another aspect of the present invention; 

FIG. 12 is a block diagram illustrating another embodiment of the invention 
directed to services that incorporates principles of the present invention; 

FIG. 13 is a block diagram illustrating another embodiment directed to services 
and having a modified relationship between vendor and service provider; and; 

FIG. 14 is a block diagram illustrating another embodiment having a modified 
relationship between a vendor, subvendors and service providers. 

While the invention is susceptible to various modifications and alternative 
forms, specific embodiments thereof have been shown by way of example in the 
drawings and will herein be described in detail. It should be understood, however, that 
it is not intended to limit the invention to the particular forms disclosed. On the 
contrary, the intention is to cover all modifications, equivalents, and alternatives falling 
within the spirit and scope of the invention as defined by the appended claims. 



The present invention is generally applicable to a computer processing system 
for a shipment transaction involving a shipper and a carrier. The present invention has 
been found to be particularly advantageous for a system which efficiently automates the 
payment of a shipment transaction and efficiently provides access to shipment 
information. 

The present invention is generally directed to a system that automates the 
shipment transaction process to thereby provide a convenient transaction protocol 
between the delivery, billing, and payment aspects of the transaction. 

In one embodiment of the present invention, a computer arrangement includes a 
main CPU communicatively coupled via the Internet to provide around the clock access 
of shipment transaction data to authorized shippers, carriers, operators of the main CPU 
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and, in more specific implementations, a separate financial institution and/or an auditor 
that is independent of the shippers, carriers, and CPU operators (and if applicable the 
separate financial institution). As is conventional with Internet communications, 
electronic notes can be included for supplemental communication with anyone in the 
shipment transaction chain. The main CPU maintains a database of all information 
relating to the shipments of the carriers and shippers, and the main CPU is used to 
analyze the shipments for auditing purposes, effect payments, to facilitate changes to the 
rating systems, and to facilitate resolution of audit discrepancies. 

When a problem arises with a shipment, for example, the shipper (or the carrier 
if preferred) can change the rating via the Internet. Moreover, the shipper can instruct 
the main CPU to delay payment. Similarly, the carrier can inform the main CPU that a 
delivery of a shipment is being delayed due to its problems in receiving payments from 
the shipper. 

By permitting the shipper access to analysis of the information database, the 
shipper can inquire of the main CPU data useful in assisting the shipper address issues, 
such as: which carrier has the best on-time delivery record, and which carrier has the 
most cost-effective service between two locations. Carriers can also use such data to 
addresses issues such as to identify the shipper that generates the most business in a 
target region. Further, all users of the system have the potential to access an abundance 
of historical data including, for example, approval history, and delivery and payment 
information. 

As shown in FIG. 1, a shipper processor 24 initiates the shipment transaction by 
acting in conjunction with a BOL rating engine 30 to generate a rated BOL. The 
shipper processor sends the rated BOL to a data processing device 34 of a shipper 
access terminal 32. The data processing device 34 generates transaction information 
and sends the transaction information to a central processor 40. The central processor 
40 identifies and centrally tracks the transaction information. A carrier processing 
device 46 receives proof of delivery information and sends this information to the 
central processor 40. The central processor 40 processes and stores all pertinent 




shipment information in a data storage unit 42 and allows immediate access to this 
information by the shipper 20, the carrier 22, and other authorized users. This reduces 
the administrative costs of the shipper 20 and the carrier 22. The central processor 40 
interfaces with an improved payment system including an issuing institution 44 and a 
5 paying institution 52. An issuing processor 45 of the issuing institution 44, maintains a 
credit account for the shipper 20 and debits the shipper's account for the cost of the 
shipment. A paying processor 54 of the paying institution 52 tenders payment to the 
carrier 24. 

FIG. 2 is a block diagram illustrating an example flowchart for programming the 
1 0 shipper processor 24 of FIG. 1 according to the present invention. According to this 
example flowchart, the shipper processor 24 receives 200 an input of relevant purchase 
order information for storage and processing using an adequate input device 202. Using 
a conventional desktop PC for example, a keyboard and mouse are adequate input 
devices. Using a more complex computer arrangement, a digital retrieving device, such 
15 as an information scanner, is used to offset some of the labor associated with this 
inputting effort. 

The shipper processor 24 processes 204 the purchase order information 
including referencing inventory control and customer information systems to generate 
206 shipment parameters. In a particular application, the shipment parameters include 

20 the identity of the carrier, identity of the receiver, the number of units, the weight of the 
shipment, the destination of the shipment, the date of shipment, and the estimated date 
of delivery. The shipper processor 24 is located at the shipper's premises so that the 
shipper processor 24 receives accurate information resulting in further reliability and 
efficiency of the system. 

2 5 The shipper processor 24 electronically sends 208 the shipment parameters to 

the BOL rating engine 30. The transmission is accomplished conventionally. The BOL 
rating engine 30 of the illustrated embodiment of FIG. 1, is designed to suit the needs of 
the particular shipper, the type of goods shipped, and to provide an interface to the 
shipper processor 24. Conventionally, BOL rating engines, which are in use today, are 




implemented using a computer processing device such as a stand-alone personal 
computer, a personal computer connected to a network, or a conventional mainframe. 

FIG. 2a is a block diagram illustrating an example flowchart for programming 
the BOL Rating Engine 30 of FIG. 1 according to the present invention. The BOL 
5 rating engine receives 2 1 6 the shipment parameters and processes 2 1 8 the shipment 
parameters. The BOL Rating Engine 30 generates 220 a rated BOL. The BOL rating 
engine 30 is programmed to an agreed upon rate structure by the shipper 20 and carrier 
22. As a result, the BOL rating engine 30 produces consistently rated BOL's. This has 
the further advantage that the shipper 20 and the carrier 22 do not have to audit the 

1 0 engine often. Existing systems require frequent auditing of the results of the BOL 

rating engine. With no post audit adjustments, the payment to the carrier 22 is definite. 

The BOL rating engine 30 sends 222 the rated BOL to the shipper processor 24. 
In a particular application, the BOL rating engine 30 is included in the shipper processor 
24. The shipper processor 24 performs the rating function of the BOL rating engine 30 

15 so that there is no need to send the shipment parameters to an external BOL rating 

engine. The shipment parameters are processed and a rated BOL is generated solely by 
the shipper processor 24. 

Another advantage associated with the process in which a rated BOL is 
produced is that only one BOL rating engine 30 is needed for the entire shipment 

2 0 transaction system. This saves duplicate efforts by the carrier 22 and ensures exact 
payment. A significant benefit of this illustrated embodiment of FIG. 1 is that the cost 
depicted on the BOL is the final cost of shipment. Therefore, the shipper 20 and carrier 
22 will immediately know the final cost of shipment before the goods are delivered. 
The BOL rating engine 30 removes ambiguity from the shipment transaction payment 

2 5 process which significantly offsets time-consuming payment disputes. 

The shipper processor 24 receives 212 the rated BOL and sends 214 the rated 
BOL to a shipper access terminal 32 located at the shipper's premises. In an alternative 
embodiment, the BOL rating engine 30 is located off the shipper's premises so that the 
shipper processor 24 can access the BOL rating engine 30 on an as-needed basis. One 
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advantage is that one standardized BOL rating engine could be electronically linked to 
multiple shipper processors thereby reducing the cost to each individual shipper. 

FIG. 3 is a block diagram illustrating an example flowchart for programming the 
data processing device 34 of FIG. 1 according to the present invention. The shipper 
access terminal 32 contains a data processing device 34 that receives 300 the rated 
BOL. The data processing device 34 validates 312 the rated BOL to ensure that the 
rated BOL contains data that is complete, error-free, and properly formatted. The data 
processing device 34 processes 312 the rated BOL and generates 316 a list of 
transaction information. The transaction information includes the information as seen in 
table 1 below. The columns in Table 1 represent the following: Data Element is the 
data that will reside in that particular element location, Length is the length of the data 
element; type is the type of data element which is either numeric or alpha-numeric, and 
Description simply describes the function of the data element if necessary. 



Table 1 - Transaction Intormation 



Data Element 


Length 


Type 


DESCRIPTION 


Shipper ED 


10 


N 


Record ID 


Dock ID 


3 


N 


Record ID 


Bill of Lading # 


15 


AN 


Record ID 


Ship Date 


8 


N 


Record ID, reporting 


SCAC 


4 


A 


Standard Carrier Alpha Code, a national 
standardized carrier identification code. 


Carrier Vendor 
Number 


10 


N 


Alternate index, allows Shipper 20 to 
specify its vendor number for a given 
carrier 22 


Customer Number 


10 


N 


Alternate index, allows shipper 20 to 
specify it's customer number for a 
given receiver 


Customer PO # 


15 


AN 


Alternate index, reporting 


Shipper Order # 


15 


AN 


Alternate index 


Vendor Order 
Number 


15 


AN 


Reporting, alternate locator, carrier 22 
PO associated with shipment 


Shipper Name 


35 


AN 




Shipper Contact 
Person 


20 


A 
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Data Element 


Length 


Type 


DESCRIPTION 


Shipper Phone # 


15 


AN 




Origin Designator 


10 


AN 




City 


20 


AN 




State 


2 


A 




ZIP Code 


9 


N 




Division Code 


2 


AN 




Reference B/L #1 


15 


AN 


Consolidated Shipments 


Reference B/L #2 


15 


AN 


Consolidated Shipments 


Reference B/L #3 


15 


AN 


Consolidated Shipments 


Bill of Lading Type 


1 


AN 


Reporting 


Shipment Mode 


3 


AN 


Less than Truck Load(LTL), Truck 
Load (TL), Rail (RAT), AIR 


Inbound, Outbound 
Flag 


1 


AN 




Prepaid, Collect Flag 


1 


AN 




COD Flag 


1 


N 




COD Amount 


9.2 


N 




Shipment Value 


9.2 


N 




Driver Name 


20 


AN 




Trailer/Car # 


15 


AN 




Trailer/CarSeal# 


15 


AN 




Import, Export Flag 


1 


AN 




# Stops 


2 


N 




Stop Off Charges 


7.2 


N 




Rated Freight Charges 


9.2 


N 




Cube Dimensions 


5 


N 




Shipment "as weight" 


7.2 


N 




Accessorial Charges 


7.2 


N 




Total Freight Chgs 


9.2 


N 




Destination Name 


25 


AN 




Destination City 


20 


AN 




Destination State 


2 


A 




Destination Zip Code 


9 


N 




Destination Area 
Code 


3 


N 




Destination Prefix 


3 


N 




Destination Phone 


4 


N 




Mileage 


5 


N 





The data processing device 34 sends the transaction information to a central 
processor 40. In one embodiment, the data processing device 34 is implemented using a 
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conventional personal computer programmed to operate under the control of an 
operating system stored in the memory. These types of computer arrangements are not 
presently programmed to conventionally interface with a central processing center and a 
processing device located at a shipper's premises. One advantage of interfacing the 
central processor 40 with shipper access terminal 32 is that the shipper access terminal 
32 can control the quantity, quality, and timing of information that is transmitted 
between the shipper processor 24 and the central processor 40. The access terminal 32 
can also control the communication sessions between the shipper processor 24 and the 
central processor 40. The shipper access terminal 32 is designed so that the shipper 20 
may directly access the transaction information. The shipper 20 will not be allowed to 
make changes to the transaction information, but is able to add additional information. 
This ensures the integrity of the transaction information. An additional advantage of the 
access terminal 32 is that the data processing device 34 can receive real-time 
information from the shipper processor 24 regarding the shipment transaction. 

In an alternative embodiment, the shipper access terminal 32 is linked to a 
magnetic stripe card reader. The card reader accepts a card and transmits the data 
contained therein to the data processing device. 34 of the shipper access terminal 32. 
The magnetic stripe card reader accepts an identification card from a user of the system. 
The identification card contains relevant user information. In an alternative application, 
the access terminal 32 is linked to a bar code reader that is designed to receive 
information from a bar code and input the bar code information into the data processing 
device 34. The bar code is printed on the BOL or on a carrier identification card. 

The data processing device 34 sends 318 the transaction information to the 
central processor 40. The design of the central processor 40 is dictated by the desired 
speed, the number of users, and the amount of data to be processed. 

FIG. 4 is a block diagram illustrating an example flowchart for programming the 
central processor 40 of FIG. 1 to manipulate the transaction information according to 
the present invention. The central processor 40 receives 402 the transaction information 
and performs 404 an integrity check on the incoming information to ensure that the 
information is correctly formatted and contains no errors. If the integrity check is 



unsuccessful, the transaction information is stored in a suspense file in a data storage 
unit 42. Once the error is corrected, the corrected transaction may be sent into the 
normal process flow. If the integrity check is successful, the central processor 40 
retrieves 406 authorized user profile lists from the data storage unit 42. 

The data storage unit 42 is essentially a memory unit that stores information 
relevant to the shipping transaction. The design of the data storage unit 42 is dictated 
by the amount of data needed to be stored. 

The authorized user profile lists represent the users and combination of users 
that are authorized to use the system. Authorized user profile lists include a shipper 
profile list, a carrier profile list, a carrier/shipper profile list, and a shipper access 
terminal profile list. The profile lists provide the cross-reference between the payment 
ID (assigned by central processor 40), an account ID (assigned by an issuing processor 
45), and a merchant number (assigned by a paying processor 54). 

An authorized shipper profile list identifies information regarding the shipper 
and the shipment as can be seen below in Table 2. 

Table 2 - Shipper Profile 



DATA ELEMENT 


WIDT 
H 


TYPE 


DESCRIPTION 


Shipper ID 


10 


N 


Uniquely identifies a legal entity using a single 
BOL system, assigned by the CP 40. 


Account ID 


16 


N 


Account # assigned to shipper 20 by issuing 
processor 54. 


Shipper Name 


32 


A/N 




Shipper Address 1 


32 


A/N 


Headquarters Address 


Shipper Address 2 


32 


A/N 




Shipper City 


28 


A/N 




Shipper 
State/Province 


3 


A/N 




Shipper Country 


3 


A/N 




Shipper Contact 


32 


A/N 




Shipper Phone 


10 


N 




Open Date 


8 


N 


Supplied by CP 40 when record is built. 
YYYYMMDD format 



17 



DATA ELEMENT 


WIDT 
H 


TYPE 


DESCRIPTION 


Date of First Activity 


8 


N 


Automatically supplied by CP 40 when first 
BOL record is received by CP 40 - 
YYYYMMDD format 


Date of Last Activity 


8 


N 


Automatically updated by CP 40 every time a 
BOL record is processed 


Current Status 


4 


A 


Valid values are OPEN, CLSD, HOLD. 
Automatically updated on effective date if 
effective date was pre-entered or as part of on- 
line transaction when effective date is set to 
today. 


Current Status Date 


8 


N 


Automatically updated by system when 
current status field is updated, YYYYMMDD 
format 


Pending Status 


4 


A 


User will key status, valid values are OPEN, 
CLSD, HOLD 


Effective Date 


8 


N 


Default to today's date with user ability to 
override to a future date. YYYYMMDD 
format 


Last update date 


8 


N 


Automatically stamped by CP 40 


Last update time 


4 


N 


Automatically stamped by CP 40. HHMM 
format 


Last Update User 


8 


A/N 


Automatically pulled from user profile by CP 
40. 



An authorized carrier profile list identifies information regarding the carrier 22 
and the shipment transaction as can be seen below in table 3. Included in the carrier 
profile is a merchant number that a paying processor 54 assigns to the carrier 22. Each 
carrier 22 can have multiple merchant numbers if desired. This allows carrier flexibility 
to assign different merchant numbers for different regions or different shippers. This 
flexibility facilitates the carrier's business management process. It is not known of 
existing systems that provide such flexibility. 

Table 3 - Carrier Profile 





DATA 


DATA 




COLUMN NAME 


WIDT 


TYPE 


DESCRIPTION 




H 








COLUMN NAME 


DATA 
WIDT 
H 


DATA 
TYPE 


DESCRIPTION 


SCAC 


4 


A/N 


4 character code that uniquely identifies 
a Carrier 22. 


Merchant Number 


10 


N 


Paying processor 54 assigns to each 
carrier. 


Carrier 22 Name 


32 


A/N 


DBA name of Carrier HQ 


Carrier Address 1 


32 


A/N 




Carrier Address 2 


32 


A/N 




Carrier City 


28 


A/N 




Carrier 

State/Province 


3 


A/N 




Carrier Country 


3 


A/N 




Carrier Contact 


32 


A/N 


Name of primary contact at Carrier HQ 


Carrier Phone 


10 


N 


Phone number of primary contact at 
Carrier HQ 


Open Date 


8 


N 


Automatically supplied by CP 40 when 
record is built. YYYYMMDD format 


Date of First 
Activity 


8 


N 


Automatically supplied by CP 40 when 
first BOL record is received by system 
on this Carrier 22 - YYYYMMDD 
format 


Date of Last Activity 


8 


N 


Automatically updated by system every 
time a BOL record is processed for this 
Carrier 22 


Current Status 


4 


A 


Valid values are OPEN, CLSD, HOLD. 
Automatically updated on effective date 
if effective date was pre-entered or as 
part of on-line transaction when 
effective date is set to today. 


Current Status Date 


8 


N 


Automatically updated by CP 40 when 
current status field is updated, 
YYYYMMDD format 


Pending Status 


4 


A 


User will key status 


Effective Date 


8 


N 


Default to today's date with user ability 
to override to a future date. 
YYYYMMDD format 


Last update date 


8 


N 


Automatically stamped by CP 40 


Last update time 


4 


N 


Automatically stamped by CP 40 
HHMM format 


Last Update User 


8 


A/N 


Automatically pulled from user profile 
lists by CP 40 
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An authorized shipper/carrier profile list identifies information regarding valid 
shipper carrier combinations as can be seen below in table 4. 



Table 4 - Shipper/Carrier Profile 



COLUMN NAME 


DATA 
WIDT 
H 


DATA 
TYPE 


DESCRIPTION 


Shipper ID 


10 


N 




Carrier SCAC 


4 


A/N 




Merchant Number 


10 


N 


Assigned by Paying processor 54. If 
blank, use default value from carrier 
profile. 


Proof of Delivery 
(POD) 


1 


A 


"Y" for POD to be required, "NT for POD 
not required 


Type of POD 


4 


A 


Identifies in what manner the POD is to 
be received. 


Auto close days 


2 


N 


Number of days after which the 
transaction will close and be paid to the 
Carrier 22 regaruiess of whether or noi 
POD has been posted. 


Open Date 


8 


N 


Automatically supplied by CP 40 when 
record is built. YYYYMMDD format 


Date of First 
Activity 


8 


N 


Automatically supplied by CP 40 when 
first BOL record is received by system - 
YYYYMMDD format 


Date of Last 
Activity 


8 


N 


Automatically updated by CP 40 every 
time a BOL record is processed 


Current Status 


4 


A 


Valid values are OPEN, CLSD, HOLD. 
Automatically updated on effective date if 
effective date was pre-entered or as part 
of on-line transaction when effective date 
is set to today. 


Current Status Date 


8 


N 


Automatically updated by CP 40 when 
current status field is updated, 
YYYYMMDD format 


Pending Status 


4 


A 


User will key status 


Effective Date 


8 


N 


Default to today's date with user ability to 
override to a future date. YYYYMMDD 
format 


Last update date 


8 


N 


Automatically stamped by CP 40 
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COLUMN NAME 


DATA 
WIDT 
H 


DATA 
TYPE 


DESCRIPTION 


Last update time 


4 


N 


Automatically stamped by CP 40 HHMM 
format 


Last Update User 


8 


A/N 


Automatically pulled from user profile 
lists 



An authorized shipper access terminal profile identifies the shipper 20 as well as 
the shipping dock. A shipper has a separate shipper access terminal profile for each 
dock. The central processor 40 assigns a different dock ID for each dock. The 
information included in the access point profile is listed below in table 5. 



Table 5 - Access Terminal Profile 



COLUMN NAME 


WIDT 
H 


TYPE 


DESCRIPTION 


Shipper ID 


10 


N 


Uniquely identifies a legal entity using a 
single BOL system 


Dock ID 


3 


N 


Uniquely identifies a particular physical 
dock location with a shipper LD. 


Account ID 


16 


N 


Issuing Processor 54 assigns. Defaults 
from shipper profile, can be overridden by 
shipper. 


Dock Name 


32 


A/N 


DBA name of dock originating BOL 


Dock Address 1 


32 


A/N 


Street address of dock originating BOL 


Dock Address 2 


32 


|_ A/N 




Dock City 


28 


A/N 




Dock State/Province 


3 


A/N 




Dock Country 


3 


A/N 




Dock Contact 


32 


A/N 




Dock Phone 


10 


N 


To be used for reporting against completion 
transaction 


Open Date 


8 


N 


Automatically supplied by CP 40 when 
record is built. YYYYMMDD format 


Date of First 
Activity 


8 


N 


Automatically supplied by CP 40 when first 
BOL record is received by system - 
YYYYMMDD format 




COLUMN NAME 


WIDT 
H 


TYPE 


DESCRIPTION 


Date of Last 
Activity 


8 


N 


Automatically updated by CP 40 every 
time a BOL record is processed 


Current Status 


4 


A 


Automatically updated by CP 40 on the 
effective date if effective date was pre- 
entered or as part of the on-line transaction 
if the effective date is changed to today. 
Valid values are OPEN, CLSD, HOLD 


Current Status Date 


8 


N 


Automatically updated by CP 40 when 
current status field is updated, 
YYYYMMDD format 


Pending Status 


4 


A 


User will key status 


Effective Date 


8 


N 


Default to today's date with user ability to 
override to a future date. YYYYMMDD 
format 


Last update date 


8 


N 


Automatically stamped by CP 40 


Last update time 


4 


N 


Automatically stamped by CP 40 HHMM 
format 


Last Update User 


8 


Am 


Automatically pulled from user profile lists 



The central processor 40 authenticates 408 the transaction information by 
comparing elements of transaction information with the authorized user profile lists. 
The elements of the transaction information used for authentication include; the identity 
5 of the shipper, the identity of the shipper's dock, and the identity of the carrier. If the 
authentication is successful, the central processor 40 assigns 410 a payment 
identification number (payment ID) to the transaction information and stores 412 the 
transaction information in the data storage unit 42. The payment ID is a unique key for 
the transaction record which the central processor 40 uses to centrally track the 

1 0 transaction. The payment ID includes specific information regarding the shipment 
transaction including; the shipper identification number, the BOL number, and the 
shipping date. The advantage of the payment ID is that it allows the central processor 
40 to more efficiently and accurately track the different actions occurring within the 
system. The payment ID can be referenced to the specific identification numbers that 

1 5 any of the users may assign. The payment ID is now considered "open". Open is a 
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term used to signify that the shipper 20 has transferred the goods to the carrier 22, and 
the carrier 22 has not yet completed the shipment. 

If the authentication is unsuccessful, the central processor 40 stores 414 the 
invalid transaction in a suspense file in the data storage unit 42. When an invalid 
transaction is stored, a notification is sent which indicates that an error has occurred and 
is in need of further review and correction. Once the error is corrected, the corrected 
transaction may be sent into the normal process path. 

The central processor 40 sends the authenticated transaction information, 
including the shipper identity and the cost of the shipment, to an issuing institution 44 
for authorization. FIG. 5 is a block diagram illustrating an example flowchart for 
programming the issuing processor 45 of FIG. 1 to perform an authorization check 
according to the present invention. The issuing institution 44 contains an issuing 
processor 45. The issuing processor 45 maintains accounts for one or more shippers. 
Each account includes information regarding credit limits, open authorizations, unpaid 
balances, and the resulting open-to-buy. Open-to-buy measures the unused credit limit. 

The issuing processor 45 receives 502 the authorization request from the central 
processor 40. The issuing processor 45 compares 504 the authorization request to the 
open-to-buy of the shipper and attempts to approve 506 the request. If the shipper 20 
has enough open to buy, the issuing processor 45 approves the authorization request. 
The issuing processor 45 stores 507 the approved authorization request and decreases 
508 the open-to-buy. The issuing processor 45 sends 510 the authorization approval to 
the central processor 40 and the central processor 40 updates the records in the data 
storage unit 42. If the authorization is successful, the payment ID is considered 
"authorized". If the authorization is unsuccessful, the issuing processor 45 sends 512 an 
authorization decline to the central processor 40. 

After the goods are delivered to a receiver, the payment ID must be "closed". 
Closed refers to providing proof of delivery (POD) of the shipment in order to complete 
the shipment transaction. POD includes the identity of the shipper, the BOL number, 
the carrier invoice number, the delivery date and time, the person acknowledging 
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receipt, and the condition of the shipment. A carrier processor 46 receives the POD and 
sends the information to the central processor 40. 

In one embodiment, the carrier processor 46 is a conventional bar code reader. 
The bar code reader is used by the carrier 22 to read a bar code on the shipment. The 
bar code reader sends the POD information to the central processor 40. 

In an alternative embodiment, the carrier processor 46 is a voice response unit 
48 (VRU). FIG. 6 is a block diagram illustrating an example flowchart for 
programming the VRU 48 according one embodiment of the present invention. In this 
embodiment, the central processor 40 extracts an open payment ID from the data 
storage unit 42. The central processor 40 sends information relating to the open 
payment ID, including the BOL number and the shipper ID, to the VRU 48. The VRU 
48 receives 602 the open BOL number. 

A standard touch-tone telephone is used to access the VRU 48. While the 
location of the telephone is not critical, locating it at the receiver's premises promotes 
efficiency, convenience, and accuracy. It is convenient and efficient because the carrier 
22 can call the VRU 48 at the exact time the shipment is delivered. It is accurate in that 
the phone number of the receiver, automatically captured by the VRU 48, will identify 
where and when the call was made. 

The VRU 48 prompts 604 the carrier 22 for the shipper ID. The VRU 48 
receives 606 the shipper ID and attempts to match 608 the entered shipper ID with an 
open shipper ID. If the shipper ID is matched, the VRU 48 prompts 61 0 the carrier 22 
for the BOL number. The VRU 48 receives 612 the entered BOL number and attempts 
to match 614 the combination of the entered BOL number and shipper ID with an open 
BOL number and Shipper ID. If the BOL number and shipper ID combination is 
matched, the VRU 48 prompts 616 the carrier 22 for condition of shipment. The VRU 
48 receives 618 the condition of shipment and sends 620 the POD information which 
includes BOL number, the shipper ID, and the condition of the shipment to the central 
processor 40. 
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If the VRU 48 cannot match either the shipper ID and the BOL number, the 
VRU 48 prompts 622 the carrier 22 to either try again or routes 624 the carrier 22 to 
customer service where the problem can be resolved. 

FIG. 7 is a block diagram illustrating an example flowchart for programming the 
central processor 40 of FIG. 1 generating a deposit file according to the present 
invention. The central processor 40 receives 702 the matched BOL number, the shipper 
ID, and the condition of the shipment from the carrier processor 46. The central 
processor 40 validates 704 the incoming data to ensure that it is error free and properly 
formatted. The central processor 40 extracts 706 the open payment ID from the data 
storage unit 42. The central processor 40 authenticates 708 the matched BOL number 
with an open payment ID. If the BOL number and payment ID are authenticated, the 
payment ID is considered complete. The central processor stores 710 the completed 
transaction and corresponding payment ID in the data storage unit 42. If authentication 
is unsuccessful, the central processor 40 stores 712 the information in a suspense file 
where the problem can be manually resolved as discussed above. 

A payment ID can be completed by the above manner or a payment ID can 
expire. A payment ID expires when a pre-programmed number of days have elapsed 
since the shipping date. This preprogrammed number of days is defined as auto close 
days in the data storage unit 42. A particular transaction is identified by the shipper and 
carrier to expire on a specific date, the effective date, whether or not the proof of 
delivery is received. On the effective date, the payment process begins. This has the 
advantage that the carrier 22 .will be paid for every shipment carried. Payment to the 
carrier 22 is expedited if proof of delivery is received. 

The central processor 40 periodically extracts 714 from the data storage unit 42 
the transactions that are listed as "completed and authorized" or "expired and 
authorized." The central processor 40 sorts and batches 716 the transactions by the 
merchant number. The central processor 40 generates 718 a deposit file 50 for those 
authorized transactions that are completed or expired and which have not been 
previously extracted. In a particular application, one deposit file 50 is created for all 
transactions completed by each carrier. The deposit file 50 is formatted so that it is 



compatible with the paying processor's 54 format. The deposit file 50 includes the 
payment ID, the account ID, the carrier identity, the BOL number, the destination city, 
the destination state, the destination zip code, and the cost of shipment. The cost of the 
shipment represents the amount that is owed by the shipper 20 and payable to the carrier 
22. 

The central processor 40 performs 720 a general integrity check on the deposit 
file 50. The integrity check includes: ensuring that the payment ID has been authorized, 
ensuring that the BOL is completed or expired, and ensuring that payment has not yet 
occurred for the particular payment ID. 

If the central processor 40 validates the deposit file 50, the processor 40 sends 722 the 
deposit file 50 to a paying processor 54 of a paying institution 52. In a particular 
application, the deposit file 50 is conventionally sent via a telephone transmission. The 
paying institution has a paying processor 54 which processes financial information and 
maintains financial accounts for the carrier 22. The paying processor 54 is generally 
designed to process financial information. The paying institution 52 maintains one or 
more accounts for each carrier 22. 

FIG. 8 is a block diagram illustrating an example flowchart for programming the 
paying processor 54 of FIG. 1 according to the present invention, The paying processor 
54 receives 802 the deposit file 50 and sends 804 a confirmation message to the central 
processor 40 that the deposit file 50 was received. 

The paying processor 54 validates 806 the incoming deposit file and generates 
808 payment to the carrier 22. The paying processor 54 tenders 810 payment to the 
carrier 24 and sends 812 this information to the central processor 40 so that the central 
processor 40 can update the data storage unit 42. In a particular application, the paying 
processor 54 tenders payment by directly paying the carrier 22. In an alternative 
embodiment, the paying processor 54 sends the payment to the carrier's bank 
conventionally through the Federal Reserve's Automated Clearing House. 

One advantage associated with the generation of payments to the carrier 22 is 
that the carrier 22 is paid relatively soon after the carrier 22 has completed the shipment. 
This provides the carrier 22 with improved cash flow and reduces the carrier's working 
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capital requirements. Another advantage is that the carrier 22 does not have to audit or 
rate the payment that saves time and money. This streamlined approach reduces the 
carrier's administrative costs associated with processing a payment. 

The paying processor 54 generates 814 a systems bill for the carrier 22. This 
5 systems bill represents the amount the carrier 22 owes for the service provided by the 
system of the present invention. The paying processor 54 sends 816 the systems bill to 
the carrier 22. The paying processor 54 sends 818 the systems bill information to the 
central processor 40 where the information is stored in the data storage unit 42. The 
paying processor 54 delivers 820 the paid shipment transactions to the issuing processor 

10 45 of the issuing institution 44. 

The issuing institution 44 maintains one or more accounts for the shipper 20 and 
extends and manages credit to the shipper 20. The issuing processor 45 maintains the 
amount paid to each carrier 22 on behalf of each shipper 20. FIG. 9 is a block diagram 
illustrating an example flowchart for programming the issuing processor 45 of FIG. 1 to 

1 5 credit a transaction according to the present invention. The issuing processor 45 

receives 902 the paid transactions from the paying processor 54. The issuing processor 
45 retrieves 904 the approved authorization list and compares 906 the authorization list 
with the paid transactions. The issuing processor 45 attempts to match 908 the paid 
transactions with an authorized transaction. If a match is made, no change is made to 

2 0 the open to buy. If a match is not made, the issuing processor 45 decreases 9 1 0 the 
open to buy. 

The issuing processor 45 posts 912 the cost of shipment for all paid transactions 
to the shipper's account thereby increasing the balance due from the shipper 20. The 
issuing processor 45 periodically bills 914 the shipper 20 for the posted financial 

2 5 transactions paid on behalf of the shipper 20 and periodically receives 9 1 6 payment 

from the shipper 20. When the issuing processor 45 receives payment, the processor 45 
posts payment to the shipper's account and increases 918 the open-to-buy. 

The issuing processor 45 communicates with the central processor 40 and sends 
information regarding shipper 20 payment and billing. The central processor 40 updates 

3 0 the data storage unit 42 with this information. 




In an alternative embodiment, the paying institution 52 is incorporated into the 
issuing institution 44. This results in one processor performing the functions of the 
issuing processor 45 and the paying processor 54. 

A further advantage of the computer processing system for a shipment 
transaction involving a shipper and a carrier is that the data storage unit 42 and central 
processor 40 interface to store and provide value-laden information to the users of the 
system. The central processor 40 provides a security check for all information entering 
and leaving the data storage unit 42. The central processor edits incoming files and 
provides on-line alarms for duplicate files, stale dated files, out of balance files, and 
files with corrupt data. The central processor 40 maintains a suspense file in the data 
storage unit 42 where incoming invalid transaction information and unmatched proof of 
delivery information are stored. With a centrally located suspense file, the problem 
resolution process is more efficient. 

The central processor 40 maintains data views and tables and stores this 
information in the data storage unit 42. The central processor 40 maintains a BOL 
Header Table for each BOL number that generally includes a summary of all 
information relating to that shipment transaction. This information is shown in the table 
6 below. The source of the particular data element is indicated in column four of table 
6. 



Table 6 BOL Header Data Elements 



Data Element 


Length 


Type 


Source 


Purpose 


Shipper ED 


10 


N 


CP 40 


Record ED 


Dock ID 


3 


N 


CP 40 


Record ED 


Account ID 


16 


N 


CP 40 


Record ED; reporting 


Bill of Lading # 


15 


AN 


Shipper 


Record ID 


Ship Date 


8 


N 


Shipper 


Record ID, reporting 


SCAC 


4 


A 


Shipper 


Alternate index, identifies 
Carrier 


Merchant # 


10 


N 


CP 40 


Alternate index, for CP 40 
usage 


Vendor # 


10 


N 


Shipper 


Alternate index, allows 
Shipper to specify its vendor 
number for a given carrier 
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Data Element 


Length 


Type 


Source 


Purpose 


Customer Number 


10 


N 


Shipper 


Alternate index, allows 
Shipper to specify it's 
customer number for a given 
receiver 


Customer PO # 


15 


AN 


Shipper 


Alternate index, reporting 


Shipper Order # 


15 


AN 


Shipper 


Alternative Index 


Vendor Order 
Number 


15 


AN 


Shipper 


Reporting, alternate locator 


Shipper Name 


35 


AN 


Shipper 


Reporting 


Shipper Contact 
Person 


20 


A 


Shipper 


Claims 


Shipper Phone # 


15 


AN 


Shipper 


Claims 


Origin Designator 


10 


AN 


Shipper 


Reporting 


City 


20 


AN 


Shipper 


Reporting 


State 


2 


A 


Shipper 


Reporting 


ZIP Code 


9 


N 


Shipper 


Reporting 


Division Code 


2 


AN 


Shipper 


Reporting 


Reference B/L #1 


15 


AN 


Shipper 


Consolidated Shipments 


Reference B/L #2 


15 


AN 


Shipper 


Consolidated Shipments 


Reference B/L #3 


15 


AN 


Shipper 


Consolidated Shipments 


Bill of Lading Type 


1 


AN 


Shipper 


Reporting 


Shipment Mode 


3 


AN 


Shipper 


LTL, TL, RAI, AIR. 


Inbound, Outbound 
Flag 


1 


AN 


Shipper 


Reporting 


Prepaid, Collect 
Flag 


1 


AN 


Shipper 


Reporting 


COD Flag j 


1 


AN 


Shipper 


Reporting 


COD Amount 


9.2 


AN 


Shipper 


Reporting 


Shipment Value 


9.2 


AN 


Shipper 


Reporting; claims 


Driver Name 


20 


AN 


Shipper 


Reporting; Claims 


Trailer/Car # 


15 


AN 


Shipper 


Reporting; claims 


Trailer/Car Seal # 


15 


AN 


Shipper 


Reporting; claims 


Import, Export Flag 


1 


AN 


Shipper 


Reporting 


# Stops 


2 


N 


Shipper 


Reporting 


Stop Off Charges 


7.2 


AN 


Shipper 


Reporting 


Rated Freight 
Charges 


9.2 


AN 


Shipper 


Payment, reporting 


Cube Dimensions 


5 


N 


Shipper 


Reporting 


Shipment "as 
weight" 


7.2 


N 


Shipper 


Reporting; claims 


Accessorial Charges 


7.2 


AN 


Shipper 


Payment, reporting 


Total Freight Chgs 


9.2 


AN 


Shipper 


Payment, reporting 
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Data Element 


Length 


Type 


Source 


Purpose 


Destination Name 


25 


AN 


Shipper 


Reporting 


Destination City 


20 


AN 


Shipper 


Reporting 


Destination State 


2 


A 


Shipper 


Reporting 


Destination Zip 


9 


N 


Shipper 


Reporting 


Code 










Destination Area 


3 


N 


Shipper 


Reporting, verification 


Code 










Destination Prefix 


3 


N 


Shipper 


Reporting, verification 


Destination Phone 


4 


N 


Shipper 


Reporting, verification 


Mileage 


5 


N 


Shipper 


Reporting 


Voucher/Check # 


12 


AN 


CP 40 


Inquiry 


Ship Date 


8 


N 


Shipper 


Life cycle tracking 


CP 40 Receipt Date 


8 


N 


CP 40 


Life cycle tracking 


Storage Insert Date 


8 


N 


CP 40 


Life cycle tracking 


VRU Extract Date 


8 


N 


CP 40 


Life cycle tracking 


Authorization Date 


8 


N 


CP 40 


Life cycle tracking 


Authorization # 


6 


AN 


Issuing 


From authorization response 








Proc.45 


feed 


Auth Response 


2 


AN 


Issuing 


From authorization response 


Code 






Proc.45 


feed 


Delivery Date 


8 


N 


CP 40 


Life cycle tracking 


Completion Date 


8 


N 


CP 40 


Life cycle tracking 


Deposit Extract Date 


8 


N 


CP 40 


Life cycle tracking 


Settlement Date 


8 


N 


Paying 


From Settlement record 








Proc.54 




Settlement DDA # 


12 


AN 


Paying 


From Settlement record 








Proc.54 




Shipper Billing Date 


8 


N 


Issuing 


From statement billing file 








Proc.45 


feed for life cycle tracking 


Delivery Area Code 


3 


N 


Carrier 


POD tracking, claims 








Proc 




Delivery Prefix 


3 


N 


Carrier 


POD tracking, claims 








Proc.46 




Delivery Phone 


4 


N 


Carrier 


POD tracking, claims 








Proc.46 




Receiver Name 


20 


A 


Carrier 


POD tracking, claims 


Receipt Condition 


1 


A 


Carrier 


Quality of service tracking, 








Proc.46 


claims 


POD ID 


15 


AN 


Carrier 


Provided by carrier 22(such 








Proc.46 


as FedEx, UPS) who has 










accepted POD system 
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In addition, the central processor 40 maintains BOL line item details from the 
transaction information. The BOL line item details generally consist of information 
relating to the goods of the shipment as can be seen below in table 7. 

Table 7 - BOL Line Item Detail Data Elements 



Data Element 


Length 


Typ 
e 


Source 


Purpose 


Shipper ID 


16 


N 


CP 40 


Record ID 


Bill of Lading # 


15 


AN 


Shipper 


Record ID 


Ship Date 


8 


N 


Shipper 


Record ID 


Product Description 


28 


AN 


Shipper 


Reporting, claims 


Product ID 


8 


AN 


Shipper 


Reporting, claims 


Product Value 


7.2 


$N 


Shipper 


Claims 


Haz Mat Flag 


1 


AN 


Shipper 


Reporting, claims 


Item Weight 


7.2 


N 


Shipper 


Reporting, claims 


Total Pes 


5 


N 


Shipper 


Reporting, claims 


Item "as weight" 


7.2 


N 


Shipper 


Reporting 


Unit of Measure 


4 


AN 


Shipper 


Reporting, claims 


Accounting Code 


25 


AN 


Shipper 


Reporting 


Item Freig^ + 
Charges 


7.2 


N 


Shipper 


Repor^"_g, claims 



In the example system application of FIG. 1, the carrier 22 will not have access 
to the BOL line item product value, but will be able to see the line item freight charges. 

A further advantage of the shipment transaction system of FIG. 1 is that the 
system allows multiple users to obtain information about the same shipment from the 
same source. Since the system supplies information from the same source, all users will 
obtain the same information at the same time. This advantage of timeliness does not 
exist in current systems. Existing systems are not known to provide a single source of 
up-to-date information regarding multiple shipment transactions. 

In an alternative embodiment, multiple users access the shipment information 
via the central processor 40. The shipment information is stored in the data storage unit 
42. The central processor 40 is electronically linked to a multitude of user stations. The 
link between the central processor 40 and a user station allows for conventional two- 



way communication. The user station is a standard personal computer comprising of a 
video display, a keyboard, a central processor, and a modem link. A user initiates a 
request for information by accessing the central processor 40 using the personal 
computer. When the user is logged into the central processor 40, the central processor 
40 prompts the user to enter a password. 

The central processor 40 provides a security check on all information requests. 
The security check is programmed such that the shipper 20 and carrier 22 are restricted 
to accessing only their own data. In addition, the processor 40 is programmed such that 
unauthorized parties are denied access. 

The central processor 40 receives informational requests from the user. The 
central processor 40 accesses the data storage unit 42 and extracts the requested 
information and transmits the information to the user's station. The advantage of such 
an information service is clear. Users will be able to obtain current information 
regarding a shipment transaction. 

In a particular application, once a user has access to the system, the central 
processor 40 will prompt the user for a range of dates of interest including the current 
day, the previous day, monthly total, yearly total,- or a specified date range. The central 
processor 40 displays the transaction information, freight amounts, shipment costs, total 
weight, and cost per pound for various types of transactions including: transactions 
added to the data storage unit, transactions with proof of delivery, transactions that have 
expired, transactions in the suspense file, transactions paid to carrier, transactions in 
transit, transactions declined, and transactions approved. 

The central processor 40 allows user's to request a particular transaction by 
entering any one of a multitude of transaction elements. The central processor 40 
identifies a particular transaction with reference to the BOL number, the shipper's 
customer number for the receiver 22, the payment ID, the carrier's customer number for 
the shipper 20, the merchant number, the account ID, the receiver's order number for 
the shipper 20, the shipper's order number for the BOL number, or the shipping date. 
This ensures compatibility between the user reference numbers such that the user can 
access information using their unique reference number assigned to the transaction. 
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The example application has additional advantages. The central processor 40 
provides to all authorized users the ability to generate custom analysis of their own data. 
This has the advantage of giving the carrier 22 the ability to extract payment data 
needed to automatically post his accounts receivable system. This is an advantage over 
existing systems that rely on manual distribution of payment against the account 
receivable system. Similarly, the shipper can extract payment data and automatically 
post his accounts payable which closes out the individual accounts payable due to each 
carrier. An advantage stemming from this automated system is that the shipper 20 does 
not need a paper invoice in order to have proof of delivery. The shipper 20 accesses the 
central processor 40 and verifies which shipments have been delivered by a particular 
carrier 22. Similarly, the carrier 22 accesses the central processor 40 to find out which 
transactions have been paid out by the shipper 20. This informational system removes 
much uncertainty from the shipment process that promotes more efficient use of 
available resources such as working capital, transportation, and personnel. 

In a particular application, the central processor 40 generates standard shipment 
transaction summary reports and provides appropriate access to the reports by various 
users. These reports include a transaction inventory control report, an open aging 
summary report, a suspense inventory control by source report, and a suspense 
inventory aging summary report. The central processor 40 uses the security profiles to 
determine which subset of transaction records will be summarized for each user. For 
example, the shipper 20 has access only to that shipper's reports. 

The inventory control report provides control totals of BOL numbers, 
merchandise value, and freight value. There are key control points including: starting 
inventory position, new BOL's from shippers, BOL's closed since the last report by the 
different methods discussed for closing BOL numbers, BOL's re-opened since the last 
report by manual proof of delivery override via customer service, BOL's canceled since 
the last report, and the ending inventory position. 

The open aging summary report contains those BOL numbers that have not been 
delivered. In addition, the freight value and merchandise value for each shipper ID and 
Dock ID are supplied for distinct age groups. The age groups include groupings by 



consecutive days since the shipping date and one group for 10 days past the shipping 
date. The suspense inventory control by source report includes merchandise and freight 
value amounts of transactions in the suspense file. Several control points for the 
suspense inventory control include: starting inventory position, new inventory added 
since last report, inventory cleared since last report, inventory deleted since last report, 
inventory undeleted since last report, and ending inventory position. The suspense 
inventory aging summary report provides an aged summary of suspense files including 
the merchandise and freight value of items that are in the suspense file by original 
receipt date. 

The central processor 40 generates detailed reports including: the inventory 
aging detail report, the suspense inventory aging detail report, and the declined item 
aging detail report. The detail reports are viewed by either the shipper ID/Dock ED/ 
account ID combination or by the carrier ID/merchant number combination. The 
inventory aging detail report lists the open BOL numbers sorted by the days in 
inventory, the shipper ID combination, and the BOL number. The inventory detail 
report lists the merchandise and freight value associated with each open BOL number. 
The suspense inventory aging detail report lists open BOL numbers by source and 
receipt date. Several fields are displayed including: shipper ID, dock ID, account ID, 
BOL number, carrier ID, freight value, and the merchandise value. The declined item 
aging detail report allows users to research the cause of exception items and lists the 
shipper ID combination, ship date, authorization time, BOL number, shipper invoice 
number, merchant number, and freight value. The declined item aging detail report is 
viewed by either shipper ID/dock ID/account ID combination, or by carrier ID/merchant 
number combination. 

The central processor 40 generates two reports that reference declined 
authorizations. These reports include the declined item summary report and the 
declined item aging report. The declined item summary report summarizes information 
regarding the declined authorization. The declined item aging report summarizes the 
information regarding the declined authorization by the shipping date. 
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Referring now to FIGs. 1 OA- IOC, according to the present invention, example 
transactional processes for implementing ship transactions are shown in the form of 
flow diagrams. FIG. 10A illustrates a manner in which accounts for shippers and 
carriers can be set up in a database for processing shipment transactions by the main 
CPU system running the operations. 

The approach shown in FIG. 10A includes five levels, with each level applicable 
to both the shipper and the carrier. At level 1010, an account is merely established for 
the shipper/carrier. Setting up the account and defining the company profile is 
administered by the central operators. For instance, if a credit institution, such as a bank 
with a credit division, owns and/or is operating the main CPU and defining 
communication access to the system, an agent of the credit institution administers these 
tasks. At level 1014, a company profile is established on the main CPU for the 
shipper/carrier. A typical company profile includes, among other particulars, contact 
information, facility locations, invoicing/debit/credit agreements for system use, and 
security information. Defining a company profile permits the shipper/carrier to be a 
user of the system with access to information processed by the main CPU for the 
shipper/carrier. At level 1016, a profile for the system administration is established to 
refine the shipper/carrier's access to the information associated within its company (the 
shipper or carrier) and organizational unit. At levels 1020 and 1024, the 
shipper/carrier's administrator defines operational profiles to define how the company 
will use the shipment transaction system. 

According to a more specific implementation, there are specific operational 
profiles and specific user profiles used by the main CPU to execute operations. These 
specific operational profiles fall into five categories: approval policies to define the 
monetary limits for each particular approver of bills; floor limits to define any rule for 
automatic approval of bills; G/L charts of accounts that are used in the process of 
allocating freight expenses to particular accounts within the company's general ledger 
system; operational filters to define characteristics of the rights of each user of the 
system within the company; and data filters that define business rules that are used to 
limit the transactions such a user can see. 



• 




The specific user profiles, which are issued and managed by the company using 
the system, are used by the system to enforce business rules with the company. These 
rules may include, for example, that every user ID: be unique, associated with only one 
organizational unit within only one company, and have only one operational filter and 
5 only one data filter associated with it. Examples of other such business rules include 
establishing that actions performed by the company are binding and that updates to the 
company's profiles be made regularly. 

At levels 1026 and 1028, the main CPU uses the previously defined information 
to establish the user relationships (depicted at level 1026) and to define carrier vendors 
10 or shipper customers, respectively, for the shipper-type company or the carrier-type 



Using the above information, the main CPU then begins to define trading . 
partners and trading parameter data for each shipper and for each carrier. This is 
depicted at level 1034 of FIG. 10A. 



well as other aspects and examples of the various example embodiments, reference may 
be made to the attached Appendix A (Training Guide) and to the attached Appendix B 
(Users Guide). For example, for information relating to the example setup information 
of FIG. 10A, reference may be made to Chapter 1 of attached Appendix B (Users 
20 Guide). 

FIG. 10B illustrates an example relationship that may be used in the shipment 
transaction system for processing freight payments. As discussed above in connection 
with FIGs. 1, 2 and 2A, upon receipt of the BOL (block 1040), the main CPU receives 
notification of delivery (block 1042) and the creditor (e.g., financial institution or bank) 

2 5 approves transaction 1044 and authorizes payment (block 1046). Payment is then made 

to the carrier as indicated in block 1048. 

FIG. 10C illustrates example processes for transactional flow, between a carrier 
and a shipper, in an example shipment transaction system referred to as "PowerTrack".® 
As illustrated in FIG. 10C, work transactions 1050 occur in response to activity input to 

3 0 the system from equipment, such as computers or other data input/output devices, 



company. 
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For additional examples of wavs to implement the above-characterized levels, as 
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operated by the shipper and the carrier. Such equipment is depicted as shipper items 
1052a, 1052b and carrier items 1054a, 1054b. The main CPU 1056 processes the data 
via Internet communication links, and interfaces with a payment-center CPU 1058 
operated by the creditorftank. As illustrated, the main CPU 1 056 and the payment- 
center CPU 1058 exchange data with each other and the items 1052a, 1052b, 1054a, 
1054b to effect proper payment in response to cleared shipment transactions. 

FIG. 1 1 illustrates an example communication path from an architectural 
perspective in which an array of computers and data routers are used in an example 
implementation of a system and method, according another aspect of the present 
invention. The computers include gateway-implemented firewalls 1064, 1066 and 
1068, and data routers in the form of hubs H1-H6 (available from 3Com). Each of the 
firewalls 1064, 1066 and 1068, and data routers H1-H6, along with other accessible 
stations in FIG. 1 1, have unique Internet addresses. The operators controllers 1076 of 
the main CPU 1078 access tier II, which is used to maintain databases for the system, 
via a path through the firewall 1066 and directly back through hub H3, or via a path out 
toward hub H2 and back through hub H3. The financial institutional (not shown) 
accesses the system, along with access by the shippers and carriers, via the Internet at 
block 1080. An outside entity, for example, an auditor can also be setup and authorized 
by the system to access information, and this typically occurs via a path through the 
Internet or the firewall 1064. 

Within tier n, database/servers are maintained in a dual manner to permit for 
execution of programs for actual system use and for user acceptance testing. Business 
logic database/servers 1081 and 1083 store an object oriented program that is used to 
execute the processing in the actual system (1081) and for user acceptance testing 
(1082). Also for the actual system (1082) and for user acceptance testing (1084), 
database/servers 1082 and 1084 provide web server functions for the Internet access at 
block 1080. Database/server 1085 is used as a background tool and is useful, for 
example, for sending and receiving information between tier II components and the 
main CPU 1078. Database/servers 1089 and 1090 store shipment transaction 
information for processing in the actual system (1089) and for processing the same data 
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for analytical purposes, for example, in response to inquiries made by the shipper, the 
carrier, the bank, or an outside entity (e.g., an auditor). 

Database/servers 1088, 1089 and 1090 can be used to duplicate the functionality 
of database/servers 1085, 1086 and 1087 for testing purposes. 

Database/servers 1091 and 1092 can be used as interactive voice response units 
adapted to be used by carriers to receive information such as delivery notification, as 
discussed previously. 

As mentioned above, for additional details concerning example implementations 
and aspects, and alternative embodiments of the present invention, reference may be 
made to the attached Appendix A (Training Guide) and to the attached Appendix B 
(Users Guide), each of which forms part of the instant patent application. 

This invention need not be limited to scenarios involving shipment of product 
and the use of physical carriers for transportation of the product or equipment, since an 
important advantage of the invention is to provide the parties involved a mechanism for 
auditing transaction informarinn to validate that a transaction occurred pronerlv and as 
agreed upon by the parties involved. The present invention also provides for application 
of the validation system in other areas, by way of example only, but should not be 
limited to these transaction scenarios. Telecommunications service vendors or 
telephone operating companies (TELCOs) are interested in providing their services to 
third party customers but do not wish to add additional infrastructure (more personnel 
and equipment) in order to engage more customers for their services. The TELCO can 
engage the services of an independent system manager that installs the necessary 
hardware and software at the location of the third party customer and is then responsible 
for ongoing service and maintenance of the equipment and software. In return, the 
system manager is paid a fee by the TELCO for the initial set up and ongoing service 
calls that may be made by the third party customer. These transactions are validated to 
ensure that they were properly completed and then payment is sent to the system 
manager for services rendered. 

In the area of services, vendors that provide a particular service usually secure 
customers through a network of agents or service providers that work directly with the 



customers to sign them up for the service. As shown in FIG. 12, a vendor 1220 through 
his vendor processor 1224 initiates the service transaction by acting in conjunction with 
a Service Quotation or Bidding engine (such as a computer-run programmed task) 1230 
to generate a quote for the cost of the service. Vendor processor 1224 sends the quote 
to a data processing device 1234 of a vendor access terminal 1232. Similar to the 
shipping scenario, the data processing device 1234 generates transaction information 
and sends the transaction information to a central processor 1240. The central processor 
1240 identifies and centrally tracks the transaction information. A service provider 
processing device 1246 receives proof of delivery or confirmation that the customer has 
received the service or is now subscribed to the service and this information is sent back 
to the central processor 1240. The central processor 1240 processes and stores all 
pertinent service subscription information in a data storage unit 1242 and allows 
immediate access to this information by the vendor 1220, the service provider 1222, and 
other authorized users. The central processor 1240 interfaces with an improved payment 
system includi™ «»n issiimo institution 1244 and a paying institution 1252. An issuing 
processor 1245 of the issuing institution 1244 maintains a credit account for the vendor 
1220 and debits the vendor's account for the service provider's fee (cost of setting up 
the customer to be able to deal directly with the vendor; or cost of getting the customer 
subscribed to the service, etc. . .) when authorized to do so. A paying processor 1254 of 
the paying institution 1252 tenders payment to the service provider 1222. 

In a specific example, a communications services provider assumes the role of 
the vendor for services ranging from telephone to cable (this includes wireless, satellite, 
video conferencing, internet services, video of demand, etc.) and an authorized agent 
assumes the role of the service provider that helps the vendor sign up customers for a 
fee. The rest of the transaction is similar to the transaction characterized in connection 
with FIG. 12 for auditing and payout purposes. Finally, tables comparable to Tables 1-7 
(see also Table 1 A and Tables 11-15) can be developed for the service provider 
locations and identifying information, as well as authorized users profiles, so that the 
auditing and payment operations pursuant to the transactions can be conducted as 
described in earlier embodiments. 
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FIG. 13 illustrates an example in which the service provider 1320 initiates the 
transaction, pursuant to customer 1321 A request for quote, and generates the transaction 
information that commences the entire transaction. With this system, vendor 1322 can 
verify that the transaction entered into by the service provider has indeed taken place 
5 and that the customer is satisfied before payment is authorized to the service provider. 
Specifically, the purchase order is processed through processor 1324 that acts in 
conjunction with quotation generating engine 1330 (such as a computer-run 
programmed task). Processor 1324 can simultaneously conduct a credit check of 
customer 1321A as per instructions of vendor before any transaction is formally entered 

10 in the system. Quotation generating engine 1330 generates a quote for the customer 

with the parameters of the service (which may also include a product purchase as part of 
the package) that he is subscribing to. By way of example, if the transaction is for 
cellular phone service, engine 1330 generates a quote for the cost of the monthly 
service, rate per minute, cost of the initial phone purchase, any weekend discounts, etc. 

1 5 typically, the quot^n engine may be a combination of application software and 
hardware (local PC or server; or a server that is remotely accessed) that contains the 
quotation algorithm and database that the user (service provider or vendor/subvendor) 
needs to generate a formal quote for the customer while initiating part of the transaction 
in the system. The engine 1320 accepts data like: name of prospect customer, address, 

2 0 phone number, # of users, type of service desired, billing particulars, credit history 

evaluation, social security numbers, etc.. The next step can include the generation of a 
customer profile (which can include information on the service provider and his 
location) and identification/customer number that can be used for tracking purposes by 
the vendor (or subvendor). This customer I.D. number can be used later to track 

2 5 payment to service provider. The quotation algorithm and database within engine 1330 

(usable by service provider 1320) can remain static for a fixed period of time, can be 
changed at regular or agreed upon intervals or can be coupled real-time to the vendor's 
database to allow for up to the minute rate changes, special discounts or promotional 
programs that may be applicable. Line 1331 indicates the coupling that can exist 

3 0 between engine 1 330 and vendor 1 322, that may be hardwired, wireless, through a 
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network, internet, satellite or any other mechanism or system that will allow for one or 
two way coupling and communication between the vendor and the service provider. 

Assuming that all details of the initial transaction are in order, processor 1324 
sends the complete purchase information to data processing device 1334 of access 
terminal 1332; processing device 1334 then sends the transaction information to central 
processor 1340. Vendor processing device 1346 receives proof of delivery of service 
provided, or confirmation that the subscriber of the service has met all of the acceptance 
criteria, and that he is now ready to be connected to the system (e.g. cellular phone 
system). Central processor 1340 processes and stores all pertinent transaction 
information in data storage unit 1342, which allows for immediate access to the 
information by the vendor 1322, the service provider 1320 and any other authorized 
users for verification of data integrity and tracking purposes. The remainder of the 
transaction is similar to embodiments already described, wherein the paying institution 
1352 and the issuing institution 1344 are involved in processing the payment to the 
service provide*- ^"ce it has hern authorized by vendor. Further, the paying anH issuing 
institution may be one and the same and can charge its fees to the vendor and service 
provider in the system as it is receiving payments from vendor 1322 and tendering 
payments to service provider 1320. 

As an example of the type of information that could be used in the 
vendor/service provider scenario, reference is made to the following Tables: 

Table 1A - Transaction Information 

(Vendor/Service Provider) 



Data Element 


Length 


Type 


DESCRIPTION 


Vendor ID 


10 


N 


Record Vendor ID 


Vendor Office ID 


3 


N 


Record Vendor Office ID 


Quotation # 


15 


AN 


Record ID; also customer PO# 


Ship Date 


8 


N 


Record ID, reporting 


Service Provider 
Terms 


4 


AN 


Payment period 


Consolidated invoice 


1 


N 


l=Yes; 2=No 


Customer Number 


10 


N 


Alternate index, allows Vendor 1220 to 
specify it's customer number 


Customer PO # 


15 


AN 


Alternate index, reporting 
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Data Element 


Length 


Type 


DESCRIPTION 


Order # 


15 


AN 


Alternate index 


Service Provider 
Order Number 


15 


AN 


Reporting, PO associated with service 
provided 


Service Provider 
Name 


35 


AN 


Name of service provider 



Table 11 -Vendor Profile 



DATA ELEMENT 


WIDT 


TYPE 


DESCRIPTION 


Vendor ID 


10 


N 


Uniquely identifies a legal entity using a single 
quotation system (e.g.engine 1230), assigned 
by the CP 1240. 


Account ID 


16 


N 


Account # assigned to Vendor 1220 by issuing 
processor 1245. 


Vendor Name 


32 


A/N 




Vendor Address 1 


32 


A/N 


Headquarters Address . 










Vendor City 


28 


a/n 




VDR. State/Province 


3 


A/N 




VDR. Country 


3 


A/N 




VDR.Contact 


32 


A/N 




VDR. Phone 


10 


N 




Open Date 


8 


N 


Supplied by CP 1240 when record is built. 
YYYYMMDD format 


Date of First Activity 


8 


N 


Automatically supplied by CP 1240 when first 
quote record is received by CP 1240 - 
YYYYMMDD format 


Date of Last Activity 


8 


N 


Automatically updated by CP 1240 every time 
a quote record is processed 


Current Status 


4 


A 


Valid values are OPEN, CLSD, HOLD. 
Automatically updated on effective date if 
effective date was pre-entered or as part of on- 
line transaction when effective date is set to 
today. 


Current Status Date 


8 


N 


Automatically updated by system when 
current status field is updated, YYYYMMDD 
format 


Pending Status 


4 


A 


User will key status, valid values are OPEN, 
CLSD, HOLD 
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DATA ELEMENT 


WIDT 
H 


TYPE 


DESCRIPTION 


Effective Date 


8 


N 


Default to today's date with user ability to 
override to a future date. YYYYMMDD 
format 


Last update date 


8 


N 


Automatically stamped by CP 1240 


Last update time 


4 


N 


Automatically stamped by CP 1240. HHMM 
format 


Last Update User 


8 


A/N 


Automatically pulled from user profile by CP 
1240. 



Table 12 - Vendor/Service Provider Profile 



COLUMN NAME 


DATA 
WIDT 


DATA 
TYPE 


DESCRIPTION 


Vendor ID 


10 


N 




Service Provider ED 


4 


a/n 




Merchant Number 


10 


N 


Assigned by Paying processor 1254. If 
blank, use default value irom service 
provider profile. 


Proof of Service 
Delivery (POD) 


1 


A 


"Y" for POD to be required, "N" for POD 
not required 


Type of POD 


4 


A 


Identifies in what manner the POD is to 
be received. 


Auto close days 


2 


N 


Number of days after which the 
transaction will close and be paid to the 
Service Provider 1222 regardless of 
whether or not POD has been posted. 


Open Date 


8 


N 


Automatically supplied by CP 1240 when 
record is built. YYYYMMDD format 


Date of First 
Activity 


8 


N 


Automatically supplied by CP 1240 when 
first quote record is received by system - 
YYYYMMDD format 


Date of Last 
Activity 


8 


N 


Automatically updated by CP 1240 every 
time a quote record is processed 


Current Status 


4 


A 


Valid values are OPEN, CLSD, HOLD. 
Automatically updated on effective date if 
effective date was pre-entered or as part 
of on-line transaction when effective date 
is set to today. 



COLUMN NAME 


DATA 
WIDT 
H 


DATA 
TYPE 


DESCRIPTION 


Current Status Date 


g 


N 


Automatically updated by CP 1240 when 
current status field is updated, 
YYYYMMDD format 


Pending Status 


4 


A 


User will key status 


Effective Date 


8 


N 


Default to today's date with user ability to 
override to a future date. YYYYMMDD 
format 


Last update date 


8 


N 


Automatically stamped by CP 1240 


Last update time 


4 


N 


Automatically stamped by CP 1240 
HHMM format 


Last Update User 


8 


A/N 


Automatically pulled from user profile 
lists 



Table 13 - Service Provider Profile 



COLUMN NAME 


DATA 
WIDT 
H 


DATA 
TYPE 


DESCRIPTION 


SP 


4 


A/N 


4 character code that uniquely identifies 
a Service Provider (SP) 1222. 


Merchant Number 


10 


N 


Paying processor 1254 assigns to each 
SP. 


SPp 22 Name 


32 


A/N 


DBA name ofSP HQ 


SP Address 1 


32 


A/N 




SP Address 2 


32 


A/N 




SP City 


28 


A/N 




SP State/Province 


3 


A/N 




SP Country 


3 


A/N 




SP Contact 


32 


Am 


Name of primary contact at SP HQ 


SP Phone 


10 


N 


Phone number of primary contact at SP 
HQ 
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COLUMN NAME 


DATA 
WIDT 
H 


DATA 
TYPE 


DESCRIPTION 


Open Date 


g 


N 


when record is built. YYYYMMDD 
format 


Date of First 
Activity 






Automatically supplied by CP 1240 
when first quote record is received by 
system on this SP 1222 - 
YYYYMMDD format 


Date of Last Activity 


8 


N 


Automatically updated by system every 
time a quote record is processed for this 
SP 1222 


Current Status 


4 


A 


Valid values are OPEN, CLSD, HOLD. 
Automatically updated on effective date 

part of on-line transaction when 
effective date is set to today. 


PiiTTPnt Status Vtatp 


g 


N 


Automatically updated by CP 1 240 
when current status field is updated, 
YYYYMMDD format 


Pending Status 


4 


A 


User will key st&tus 


Effective Date 


8 


N 


Default to today's date with user ability 
to override to a future date. 
YYYYMMDD format 


Last update date 


8 


N 


Automatically stamped by CP 1240 


Last update time 


4 


N 


Automatically stamped by CP 1240 
HHMM format 


Last Update User 


8 


A/N 


Automatically pulled from user profile 
lists by CP 1240 



Table 14 - Vendor/Service Provider Access Terminal Profile 



COLUMN NAME 


WIDT 
H 


TYPE 


DESCRIPTION 


Vendor ID 


10 


N 


Uniquely identifies a legal entity using a 
single quotation system (e.g engine 1230) 


SPED 


3 


N 


Uniquely identifies a particular physical 
location with a Service Provider ID. 


Account ID 


16 


N 


Issuing Processor 1254 assigns. Defaults 
from SP profile, can be overridden by 
vendor 
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COLUMN NAME 


WIDT 
H 


TYPE 


DESCRIPTION 


SP Name 


32 


A/N 


DBA name of SP originating quote 


SP Address 1 


32 


A/N 


Street address of SP originating quote 


SP Address 2 


32 


A/N 




SP City 


28 


A/N 




SP State/Province 


3 


A/N 




SP Country 


3 


a/n 




SP Contact 


32 


A/N 




SP Phone 


10 


N 


To be used for reporting against completion 
transaction 


Open Date 


8 


N 


Automatically supplied by CP 1240 when 
record is built. YYYYMMDD format 


Date of First 
Activity 


8 


N 


Automatically supplied by CP 1240 when 
first quote record is received by system - 
YYYYMMDD format 


Date of Last 
Activity 


8 


N 


Automatically updated by CP 1 240 every 
time a quote record is processed 


Current Status 


4 


A 


Automatically updated by CP 1240 on the 
effective date if effective date was pre- 
entered or as part of the on-line transaction 
if the effective date is changed to today. 
Valid values are OPEN, CLSD, HOLD 


Current Status Date 


8 


N 


Automatically updated by CP 1 240 when 
current status field is updated, 
YYYYMMDD format 


Pending Status 


4 


A 


User will key status 


Effective Date 


8 


N 


Default to today's date with user ability to 
override to a future date. YYYYMMDD 
format 


Last update date 


8 


N 


Automatically stamped by CP 1240 


Last update time 


4 


N 


Automatically stamped by CP 1240 
HHMM format 


Last Update User 


8 


A/N 


Automatically pulled from user profile lists 



Table 15 - Service Quotation Data Elements 



Data Element 


Length 


Type 


Source 


Purpose 


Vendor ID 


10 


N 


CP 1240 


Record ID 


SPID 


3 


N 


CP 1240 


Record ID 


Account ID 


16 


N 


CP 1240 


Record ID; reporting 
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Data Element 


Length 


Type 


Source 


Purpose 


Quotation # 


15 


AN 


SP 


Record ID 


Service Date 


8 


N 


SP 


Record ID, reporting 


SPAC 


4 


A 


SP 


Alternate index, identifies 
Service Provider 


Merchant # 


10 


N 


CP 40 


Alternate index, for CP 1240 
usage 


Vendor # 


10 


N 


SP 


Alternate index, allows SP to 
specify its vendor number for 
a given vendor 


Customer Number 


10 


N 


Vendor/ 
SP 


Alternate index, allows 
Vendor or SP to specify it's 
customer number 


Customer PO # 
(Quote #) 


15 


AN 


SP 


Alternate index, reporting 


SP Order # 


15 


AN 


SP 


Alternative Index 


Vendor Order 
Number 


15 


AN 


SP 


Reporting, alternate locator 


Vendor Name 


35 


AN 


SP 


Reporting 


Vendor Contact 
Person 


20 


A 


SP 


Claims 


Vendor Phone # 


15 


AN 


SP 


Claims 


Origin Designator 


10 


AN 


SP 


Reporting 


City 


20 


AN 


SP 


Reporting 


State 


2 


A 


SP 


Reporting 


ZIP Code 


9 


N 


SP 


Reporting 


Division Code 


2 


AN 


SP 


Reporting 



Table 16 - Service Quotation Line Item Detail Data Elements 



Data Element 


Length 


Typ 
e 


Source 


Purpose 


Vendor ID 


16 


N 


CP 1240 


Record ID 


Quotation/PO # 


15 


AN 


SP 


Record ID 


Service Date 


8 


N 


SP 


Record ED 


Service Description 


28 


AN 


SP 


reporting, claims 


Serrvice Program ID 


8 


AN 


SP 


reporting, claims 
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The above-described system can be used by authorized representatives (or 
agents) to help customers subscribe to other types of services for a fee. Travel agents are 
already commission-based when they assist customers in making reservations for 
lodging, air and land transportation; however, they can now be tied to this system for 
faster processing of payments back to them in return for a fee that can be charged by the 
banking institution for this service. 

The system can also be used in the area of providing wireless communications 
services (or entertainment services such as satellite programming or satellite 
communications) to third party customers , via authorized or empowered 
representatives, to verify that customers have the correct equipment and software to 
receive the service from the communications vendor. The representative is involved in 
preliminary issues of credit checks and programming selection and is the normal contact 
for the customer if any service issues arise. The representative is paid a fee for the 
initial set up and ongoing support of the customer using the transaction validation 
system described to ensure that the work was properlv done and that oayment is issued 
to the authorized representative by an authorized user of the system. This system is also 
applicable in the area of video conferencing services, where a third party customer is 
interested in working with the communication services vendor through a 
communications consultant. The consultant helps to set up the equipment and software 
required to connect to the video conferencing network and is there to service the 
customer's needs on an ongoing basis. The consultant provides all of the services for a 
fee to be paid by the communications service vendor. 

Software or information technology (IT) developers also benefit from this 
system when using IT consultants that work closely with third party customers, 
specifically when such customers need help in upgrading and maintaining their systems. 
The IT consultants are paid using the transaction validation system described for 
services rendered. Companies selling products through online (Internet) agents such as 
Buy.com, eBay.com or eToys.com or via a normal telephone (such as florists, catalog 
purchases, QVC, Home Shopping Network, etc..) also benefit from this system. 



The role of a "vendor" is becoming blurred as more companies start to shift their 
manufacturing of products to companies that specialize in the manufacture of that type 
of product in response to the customer's demand for lower cost, shorter lead times and 
better technology. This is especially true in the area of computers and consumer 
5 electronics. OEM companies like IBM and HP, in the computer area, and Ericsson and 
Qualcomm, in the mobile communications area, have shifted much of their 
manufacturing to contract manufacturers such as Solectron and Flextronics. Contract 
manufacturers have the capability of taking the engineered designs of these customers 
and manufacturing them at the lowest possible cost due to their purchasing strength and 

1 0 logistic capabilities. They in turn will ship the completed product to the end customer 
(e.g. Circuit City, Best Buy, and etc..) on behalf of the OEM and invoice that customer 
if the OEM chooses that method. Here the contract manufacturer has control of the 
carrier that will be shipping the product to the OEM's customer. In the eyes of the 
customer the vendor is still the OEM that is the party receiving the P.O. and whom they 

15 are holding responsible if the oroduct has a problem or is not shipped on time. The 
emerging vendor/subvendor relationship, including the service provider (providing 
transportation services in this case) who is involved in this type of transaction, requires 
the banking institution to ultimately pay the service provider and subvendor when it is 
authorized by the vendor to do so. This is another opportunity for the banking 

2 0 institution to expedite auditing and financial negotiations due to the presence of the 
subvendor in this equation. 

Referring now to the example process depicted in connection with FIG. 14, 
vendor/OEM 1420 receives a purchase order through vendor processor 1424 A from a 
customer for product/equipment with a requested shipping date. Processor 1424A 

2 5 initiates a transaction by acting in conjunction with subvendor processor 1424B and 

quotation generating engine 1430 to generate a quote for the equipment and shipping 
date for the customer. Subvendor processor 1424B sends the quotation to vendor 
processor 1424A and to a data processing device 1434 of the subvendor access terminal 
1432. Vendor can now add their markup before advising customer of equipment ship 

3 0 date but now knows what it owes the subvendor if the entire transaction occurs as 
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planned. The data processing device 1434 generates the transaction information and 
sends the transaction information to the central processor 1440, which in turn identifies 
and centrally tracks the transaction information. A service provider device 1446 
receives proof of delivery information and sends this information to the central 
processor 1440. Central processor 1440 processes and stores all pertinent information 
in a data storage unit 1442 and allows immediate access to their information by the 
vendor, subvendor and the service provider. When vendor processor 1424A receives 
confirmation or proof of delivery then it, or its authorized agent/user, will authorize 
payment to subvendor. This is also a signal to subvendor that the subvendor controlled 
service provider 1422 can now be paid. Service provider's 1422 notice to central 
processor 1440 that delivery is confirmed reaches both vendor and subvendor 
simultaneously through central processor 1440 to ensure a closed loop system. The 
issuing processor 1445, of the issuing institution 1444, maintains a credit account for 
both the vendor 1420 and subvendor 1421 and debits the vendor's account for the cost 
of the entire project (which was calculated with a different algorithm initially to avoid 
disclosing cost information to the end customer) when payment to subvendor is 
authorized by vendor. Subvendor's account is debited by issuing processor 1445 for 
cost of service provider's 1422 service when authorized by subvendor. The remaining 
part of the auditing and payment system is substantially similar to embodiments 
described above. 

Referring briefly to Tables 1-7, the content of these tables for the 
subvendor is similar to that of the shipper/carrier scenario described earlier since the 
service provider is acting like a manufacturer of goods that needs to ship product to a 
customer via a carrier. Additional profiles similar to Table IB (Transaction Information 
- Vendor/Subvendor/Service Provider), Table 8 (Vendor Profile) and Table 9 
(vendor/subvendor profile) would be developed for a particular transaction. The 
subvendor can provide part of the service package that the vendor has contracted him to 
do and have the package delivered to the end customer through another party that will 
act as a service provider. For instance, IBM contracts with a subvendor to install a 
software update for a global IBM customer with a presence in Costa Rica. The 
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subvendor in turn contracts with a local Costa Rican software consultant (service 
provider) to perform the actual software update at the customer site. Once the tables 
have been established and put into the system (and the authorized users identified) the 
auditing and payment operations can be performed substantially the same as described 
5 in earlier embodiments. 



Table IB - Transaction Information 

(Vendor/Subvendor/Service Provider) 

10 





Z)ate Element 


Length 


Type 


DESCRIPTION 




Vendor ID 


10 


N 


Record Vendor ID 




Vendor Office ID 


3 


N 


Record Vendor Office ID 


a 


Quotation # 


15 


AN 


Record ID; also customer PO# 


in 

ru 


Ship Date 


8 


N 


Record ID, reporting 


Subvendor Terms 


4 


AN 


Payment period 


Consolidated invoice 


1 


N 


l=Yes; 2=No 


Customer r dumber 




N 


Alternate indc;;, allows Vendcrl42C to 


M 








specify it's customer number for a 


'-..J 








given receiver 




Customer PO # 


15 


AN 


Alternate index, reporting 


U 
W 


Order # 


15 


AN 


Alternate index 




Subvendor Order 


15 


AN 


Reporting, PO associated with shipment 


: y 


Number 








a 


Service Provider 


35 


AN 


Name of service provider or shipping 


a 


Name 






company 



Table 8 - Vendor Profile 



DATA ELEMENT 


WIDT 
H 


TYPE 


DESCRIPTION 


Vendor ID 


10 


N 


Uniquely identifies a legal entity using a single 
quotation system (e.g.engine 1430), assigned 
by the CP 1440. 


Account ED 


16 


N 


Account # assigned to Vendor 1420 by issuing 
processor 1445. 


Vendor Name 


32 


A/N 




Vendor Address 1 


32 


AM 


Headquarters Address 
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DATA ELEMENT 


WIDT 
H 


TYPE 


DESCRIPTION 










Vendor City . 


28 


A/N 




VDR. State/Province 


3 


A/N 




VDR. Country 


3 


A/N 




VDR.Contact 


32 


A/N 




VDR. Phone 


10 


N 




Open Date 


8 


N 


Supplied by CP 1440 when record is built. 
YYYYMMDD format 


Date of First Activity 


8 


N 


Automatically supplied by CP 1440 when first 
quote record is received by CP 1440 - 
YYYYMMDD format 


Date of Last Activity 


8 


N 


Automatically updated by CP 1440 every time 
a quote record is processed 


Current Status 


4 


A 


Valid values are OPEN, CLSD, HOLD. 
Automatically updated on effective date if 
effective date was pre-entered or as part of on- 
line transaction when effective date is set to 
today. 


Current Status Date 


8 


N 


Automatically updated by system when 
current status field is updated, YYYYMMDD 
format 


Pending Status 


. 4 


A 


User will key status, valid values are OPEN, 
CLSD, HOLD 


Effective Date 


8 


N 


Default to today's date with user ability to 
override to a future date. YYYYMMDD 
format 


Last update date 


8 


N 


Automatically stamped by CP 1440 


Last update time 


4 


N 


Automatically stamped by CP 1440. HHMM 
format 


Last Update User 


8 


A/N 


Automatically pulled from user profile by CP 
1440. 



Table 9 - Vendor/Subvendor Profile 



COLUMN NAME 


DATA 
WIDT 
H 


DATA 
TYPE 


DESCRIPTION 


Vendor ID 


10 


N 




Subvendor ED 


4 


A/N 
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COLUMN NAME 


DATA 
WIDT 
H 


DATA 
TYPE 


DESCRIPTION 


Merchant Number 


10 


N 


Assigned by Paying processor 1454. If 
blank, use default value from subvendor 
profile. 


Proof of Delivery 
(POD) 


1 


A 


"Y" for POD to be required, "N" for POD 
not required 


Type of POD 


4 


A 


Identifies in what manner the POD is to 
be received. 


Auto close days 


2 


N 


Number of days after which the 
transaction will close and be paid to the 
Subvendor 1422 regardless of whether or 
not POD has been posted. 


Open Date 


8 


N 


Automatically supplied by CP 1440 when 
record is built. YYYYMMDD format 


Date of First 
Activity 


8 


N 


Automatically supplied by CP 1440 when 
first quote record is received by system - 
YYYYMMDD format 


Date of Last 
Activity 


8 


N 


Automatically updated by CP 1440 every 
time a quote record is processed 


Current Status 


4 


A 


Valid values are OPEN, CLSD, HOLD. 
Automatically updated on effective date if 
effective date was pre-entered or as part 
of on-line transaction when effective date 
is set to today. 


Current Status Date -1 


8 


N 


Automatically updated by CP 1440 when 
current status field is updated, 
YYYYMMDD format 


Pending Status 


4 


A 


User will key status 


Effective Date 


8 


N 


Default to today's date with user ability to 
override to a future date. YYYYMMDD 
format 


Last update date 


8 


N 


Automatically stamped by CP 1440 


Last update time 


4 


N 


Automatically stamped by CP 1440 
HHMM format 


Last Update User 


8 


A/N 


Automatically pulled from user profile 
lists 



In another embodiment it is envisioned that the different users of the 
system may be located remotely from the transaction validation system and are 



53 



accessing the system and its database through system processors or computer-like 
mechanism. For instance, the vendor, subvendor or service provider may be in a foreign 
country but accessing the transaction system and the central processor arrangement in 
the U.S. via a computer or a network that connects that user with the transaction system 
that may be in the U.S. The transaction system and its users need not be co-located. 
Specifically in Figures 12 and 13, vendor processor 1224 or service provider processors 
may be tapped into remotely, but to the system these users may appear to be local and 
using their processors locally to access and use the system. 

Accordingly, the present invention provides, among other aspects, a computer 
processing system for a shipment transaction involving a shipper and a carrier. Further, 
the present invention provides a computer processing system and method for auditing a 
transaction between a vendor and a service provider in the area of services. Finally, the 
present invention provides a computer processing system and method for auditing a 
transaction between a vendor, subvendor and a service provider. Other aspects and 
embodiments of the present invention will be apparent to those skilled in the art for 
consideration of the specification and practice of the invention disclosed herein. It is 
intended that the specification and illustrated embodiments be considered as exemplary 
only, with a true scope and spirit of the invention being indicated by the following 
claims. 



54 



1 What is claimed is: 




'or transaction pr jcessing involving transaction information related to services 
by one of a plur .lity of vendors and processed by one of a plurality of service 
providers, a transaction v ilidation system for auditing comprising: a central processor 
arrangement programmec 1 and configured to maintain data relating to an authorized 
profile list criterion that i icludes information about authorized users empowered to 

6 authorize payment by the vendor, and programmed and configured to process the 

7 transaction information b y determining whether the transaction information satisfies the 

8 authorized profile list crii erion, and using the authorized profile list criterion to generate 

9 information for auditing i transaction between said one of a plurality of vendors and 
10 said one of a plurality of service providers 



A transactiouf'validation system for auditing according to claim 1 . wherein said 
system further includes a means for generating a quotation coupled to said central 
processor arrangement. 



r am^fgemei 



transaction processing 
(fovided by a vendor, said 
plurality of service providers 
system for auditing comprisin 
configured to maintain data 

6 information about authorized 

7 the service provider, and 

8 information by determining 

9 profile list criterion, and 

1 0 information for auditing a 

11 service providers. 



involving transaction information related to services 
transaction information initially being generated by one of a 
irior to processing by said vendor, a transaction validation 
g: a central processor arrangement programmed and 
r« lating to an authorized profile list criterion that includes 
users empowered to authorize payment by the vendor to 
and configured to process the transaction 
vfhether the transaction information satisfies the authorized 
the authorized profile list criterion to generate 
transaction between said vendor and said one of a plurality of 

V 



1 usin ; 
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4/ A transaction validation system for auditing according to claim 3, wherein said 
system further includes a means for generating a quotation coupled to said central 





transaction processing nvolving transaction information related to services 
wided by a vendor and a ph irality of subvendors and processed by one of a plurality 
of subvendor controlled serviae providers, a transaction validation system for auditing 
comprising: a central processor arrangement programmed and configured to maintain 
data relating to an authorized {profile list criterion that includes information about 
authorized users empowered to authorize payment by the vendor and subvendors, and 
programmed and configured to process the transaction information by determining 
whether the transaction infoi nation satisfies the authorized profile list criterion, and 
using the authorized profile ist criterion to generate information for auditing a 
transaction between said vei dor and both of said plurality of subvendors and said 
plurality of subvendor contr >lled service providers. 



A transaction validation system accordingteTclaim 5, wherein said system further 
includes a means for processing transactions for each of said vendor and said 
subvendor, said processing transaction means coupled to said central processor 



7. A transaction>validation system according to claim 2, wherein said system 
further includes^ means for processing transactions for each of said vendor and said 
ider, said processing transaction means coupled to said central processor 



1 877 A transaction val dati< 
Q^j^B/tnmsaction means is a 



ion system according to claim 8, wherein said processing 
remotely. 




9. A transaction processing system involving transaction information related to 
ices provided from one on a plurality of vendors and processed by one of a plurality 

if service providers, a method for validating a service transaction for auditing 
comprising: / 

generating transaction information prior to processing by vendor; 
providing an authorised profile list criterion that includes information about 
authorized users empowered to authorize payment by the vendor; 

a rangement, maintaining data relating to the authorized 
pr )cessing the transaction information by determining whether 
satisfies the authorized profile list criterion, and by using the 

1 1 authorized profile list crit rion to generate information for auditing a transaction 

1 2 between said one of a plu ality of vendors and said one of a plurality of service 

1 3 providers. 

10. A method for val 
including sending 
set of transaction i 



using a computer 
profile list criterion and 
the transaction informatioi 



11. A method for vali< 
including informing the 
providers, and using th( 
payment thereof in 
criterion. 



1 12. The method acc arding 

2 related information to s aid 



provided from a vendo 
\ 



dating a service transaction, according to claim 9, further 
tted information from an external device and generating a 
therefrom. 

idating a service transaction, according to claim 10, further 
computer arrangement of provision of the service by the service 
computer arrangement to audit the service transaction and 

to the transaction information and the authorized profile list 



to claim 9, further including communicating service 
computer arrangement from remote location. 



1 13. For transaction processing involving transaction information related to services 



and one of a plurality of subvendors and processed by one of a 
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using a computer arrai 
profile list criterion and proce 
the transaction information sa 



plurality of subvendor controlled service providers, a method for validating a service 
transaction for auditing comp ising: 

generating transaction information prior to processing by subvendor; 
providing an authorizt d profile list criterion that includes information about 
authorized users empowered t ) authorize payment by the vendor; and 

gement, maintaining data relating to the authorized 
ising the transaction information by determining whether 
isfies the authorized profile list criterion, and by using the 
authorized profile list criterioi to generate information for auditing a transaction 
between said one of a pluralit 1 of vendors and said one of a plurality of service 
providers. 

14. A system for billing a vendor and subvendor, and paying a service provider and 
a subvendor for a completed fcervice-related transaction, comprising: 

means for receiving a set of transaction information including the cost of service 
from a central processor arra igement; and 

a credit account for the vendor, for verifying that the 
t o fund the cost of service, for indicating when the account 



means for processing 
vendor has sufficient credit 
for the vendor should be debited, and for indicating when payment to the service 



provider and subvendor sho 
cost of service. 



ild be tendered, and for notifying a financial institution the 



15. A method for billinj ; 
a subvendor for a complete I 

receiving a set 
central processor arrangement; 

using a computer 
verifying that the vendor h s 
when the account for the 



a vendor and subvendor, and paying a service provider and 
service-related transaction, comprising: 
ction information including the cost of service from a 
and 

for processing a credit account for the vendor, for 
sufficient credit to fund the cost of service, for indicating 
should be debited, for indicating when payment to the 



ve idor 
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(57) ABSTRACT 

A computer processing system for a shipment ti 
involving a shipper and a carrier. The system is particularly 
suited to efficiently automate the payment of a shipment 
transaction and to efficiently provide access to relevant 
shipment information. The system includes a shipper pro- 
cessor which receives purchase order information and assists 
in generating a bill of lading for the transaction. A shipper 
access terminal interfaces between the shipper processor and 
a central processor arrangement to control the quantity, 
quality, and timeliness of information transferred to the 
central processor arrangement. The central processor 
arrangement stores selective shipment information and gen- 
erates reports regarding the transactions. A carrier processor 
provides proof of delivery to the central processor arrange- 
ment. The central processor communicates with one or more 
financial institutions so that the carrier is paid and shipper 
billed for the relevant transaction. 
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SHIPMENT TRANSACTION SYSTEM AND 
METHOD 

This is a Continuation of application Ser. No. 08/748,243 
filed Nov. 12, 1996 now U.S. Pat. No. 5,910,896, which 
application is incorporated herein by reference. 

FIELD OF THE INVENTION 

The present invention relates to a computer processing 
system for a shipment transaction involving a shipper and a 
carrier. 

BACKGROUND OF THE INVENTION 

Processing shipment transactions between a shipper and a 
carrier has been a manually intensive effort and has expe- 
rienced little change. Generally, the shipment transaction 
process involves a goods transport path and a payment 
process path. The goods transport path typically starts when 
a carrier picks up the goods at the shipper's warehouse dock. 
The carrier receives a copy of a transaction document, 
sometimes referred to as a bill of lading (BOL), from the 
shipper. This type of transaction document includes infor- 
mation associated with the shipment transaction which is 
used by the shipper and carrier to track the shipment of 
goods. The carrier transports the goods to the receiver where 
the receiver signs a copy of the BOL to verify receipt of the 
goods. After the carrier has delivered the goods to the 
receiver, the carrier also submits the receiver's signed copy 
of the BOL to the carrier's headquarters. 

The payment process path starts when the carrier picks up 
the goods from the shipper. The carrier sends a copy of the 
BOL to the carrier's headquarters for processing. The carrier 
headquarters rates the BOL. Kating involves determining the 
shipment cost which takes into the account various shipment 
parameters such as the size, weight, type of material, and 
destination of the shipment. The carrier creates an invoice, 
sets up an accounts receivable, and sends the invoice to the 
shipper's accounts payable department. The shipper, either 
internally or via a third party, audits the invoice to ensure the 
final cost is proper. 

One of the more burdensome aspects of the traditional 
process involves reaching agreement as to the final cost. If 
there is a dispute as to final cost, the shipper and carrier 
begin a burdensome and sometimes lengthy negotiation 
process in an attempt to settle the dispute. If the dispute is 
resolved, the shipper sets up an accounts payable for the 
transaction. The shipper will then send payment to the 
carrier and clear the accounts payable. Traditionally, the 
process for paying the carrier and clearing the accounts 
payable involves several manually intensive steps. Upon 
receipt of payment, the carrier clears the accounts receiv- 
able. Traditionally, the process for clearing an accounts 
receivable includes the carrier manually inputting final pay- 
ment information into the accounts receivable system. 

The traditional approach can lead to many disadvantages 
for a transaction between one shipper and one carrier. 
Typically, however, there are multiple carriers and shippers 
involved in multiple transactions, which makes the situation 
more complex, and that much more slow and inefficient. The 
process is manually intensive in that it relies on the hard 
copy of the BOL for proof of delivery and payment, result- 
ing in a series of repetitive and time consuming steps. Also, 
each BOL is often rated multiple times by multiple parties 
creating excessive redundancy. 

Traditional shipment transaction systems are also highly 
susceptible to billing errors and fraud. For example, there is 
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no connection between the delivery of goods and when the 
snipper is billed for delivery. This may result in double 
billing, no billing at all, or overbilling the shipper for freight 
delivery charges. Also, auditing error may occur which 

5 results in incorrect billing or payment. In addition, the 
carrier waits a disproportionately long time for payment 
while the invoice is being audited and/or disputed. For 
example, traditionally, a delivery takes about five days 
whereas payment takes about thirty days. This unnecessary 

10 delay adversely affects the carrier's working capital 

Additional costs arise as a result of the existing ineffi- 
ciencies. Many of the costs are individually small, but very 
large in the aggregate. For example, the carrier incurs 

is administrative costs including: the cost to create and deliver 
the initial invoice, costs of resolving billing disputes, costs 
of providing a signed copy of the BOL to the shipper, and 
costs of posting accounts receivable. The shipper incurs 
similar administrative costs. 

20 An additional disadvantage involves the inability to 
obtain immediate information regarding a shipment. Since 
the process is largely conducted manually, it is very difficult 
to track a shipment. To learn of the status of shipment or 
payment, there are various manual steps involved. For 

25 example, if the shipper wants to know if the carrier delivered 
the goods and if the payment has been made, the shipper 
must call the carrier and the appropriate financial institution. 
There have been numerous attempts to improve the exist- 

3Q ing shipment and payment process. Some improvements 
have been made to each separate step of completing a 
shipment transaction, but the entire method remains rela- 
tively unchanged. For example, freight agents are used by 
siuppcib to schedule shipments auu iu piucess the invui^i; 
from the carrier. Also, third party service providers have 
taken over the role of managing the shipper's accounts 
payable department. 

Another attempt to improve this burdensome transaction 
process involves the use of the Internet. Carriers have 

40 offered Internet access to their shipment information. Ship- 
pers access the carrier's Internet address and find out the 
immediate status of the shipment. A disadvantage of this 
system arises when, as in many applications, the shipper is 
using multiple carriers. In this typical situation, the shipper 

45 separately accesses the address of each carrier in order to 
find out the status of each shipment. This is unduly time 
consuming. 

Another disadvantage of traditional systems is that the 
shipper's reference number and the carrier's reference num- 

50 ber are not compatible. The carrier maintains the shipment 
data, so the shipper accesses the data using the carrier's 
reference number rather than the shipper's reference num- 
ber. The shipper and carrier track each shipment using 
multiple reference numbers. 

55 These various attempts to improve the overall process 
have fallen short of providing a convenient and cost effective 
system to process a shipment transaction. 

SUMMARY OF THE INVENTION 
60 According to one application, the present invention is 
directed to a shipment transaction system for processing 
transaction information related to goods shipped from a 
shipper by a carrier. The system comprises a means for 
accepting shipment information at the shipper's premises. 
65 The system provides a data processing means at the ship- 
per's premises, responsive to the shipment information, 
arranged and configured to generate a set of transaction 
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information. The transaction information includes informa- 
tion associated with the carrier and the time at which the 
shipment is initiated at the shipper's premises. The system 
uses a central processor arrangement, responsive to the 
transaction information, and located remote from the ship- 
per's premises, for processing selective information regard- 
ing the shipment. The system provides means for informing 
the central processor arrangement of delivery of goods by 
the carrier. The central processor arrangement, responsive to 
informing means, using the transaction information to audit 
the shipment transaction and payment thereof. 

The above summary of the present invention is not 
intended to describe each illustrated embodiment, or every 
illustrated implementation, of the present invention. This is 
the purpose of the figures and of the detailed description that 
follows. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Other aspects and advantages of the invention will 
become apparent upon reading the following detailed 
description and upon reference to the drawings in which: 

FIG. 1 is a block diagram illustrating a specific embodi- 
ment which incorporates principles of the present invention. 

FIG. 2 is a block diagram illustrating an example flow- 
chart for programming the shipper processor 24 of FIG. 1 
according to the present invention; 

FIG. 2a is a block diagram illustrating an example flow- 
chart for programming the BOL rating engine 30 of FIG. 1 
according to the present invention; 

FIG. 3 is a block diagram illustrating an example flow- 
chart for programming the data processing device 34 of FIG. 
1 according to the present invention; 

FIG. 4 is a block diagram illustrating an example flow- 
chart for programming the central processor 40 of FIG. 1 
manipulating the transaction information according to the 
present invention; 

FIG. 5 is a block diagram illustrating an example flow- 
chart for programming the issuing processor 45 of FIG. 1 
authorizing a transaction according to the present invention. 

FIG. 6 is a block diagram illustrating an example flow- 
chart for programming the VRU unit 48 according to the 
present invention. 

FIG. 7 is a block diagram illustrating an example flow- 
chart for programming the central processor 40 of FIG. 1 
generating a deposit file according to the present invention. 

FIG. 8 is a block diagram illustrating an example flow- 
chart for programming the paying processor 54 of FIG. 1 
according to the present invention. 

FIG. 9 is a block diagram illustrating an example flow- 
chart for programming the issuing processor 45 of FIG. 1 
crediting a transaction according to the present invention. 

While the invention is susceptible to various modifica- 
tions and alternative forms, specific embodiments thereof 
have been shown by way of example in the drawings and 
will herein be described in detail. It should be understood, 
however, that it is not intended to limit the invention to the 
particular forms disclosed. On the contrary, the intention is 
to cover all modifications, equivalents, and alternatives 
falling within the spirit and scope of the invention as defined 
by the appended claims. 

DETAILED DESCRIPTION OF THE 
INVENTION 

The present invention is generally applicable to a com- 
puter processing system for a shipment transaction involving 
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a shipper and a carrier. The present invention has been found 
to be particularly advantageous for a system which effi- 
ciently automates the payment of a shipment transaction and 
efficiently provides access to shipment information. 
5 The present invention is generally directed to a system 
which automates the shipment transaction process to thereby 
provide a convenient transaction protocol between the 
delivery, billing, and payment aspects of the transaction. 
As shown in FIG. 1, a shipper processor 24 initiates the 
10 shipment transaction by acting in conjunction with a BOL 
rating engine 30 to generate a rated BOL. The shipper 
processor send the rated BOL to a data processing device 34 
of a shipper access terminal 32. The data processing device 
34 generates transaction information and sends the transac- 
15 tion information to a central processor 40. The central 
processor 40 identifies and centrally tracks the transaction 
information. Acarrier processing device 46 receives proof of 
delivery information and sends this information to the 
central processor 40. The central processor 40 processes and 
20 stores all pertinent shipment information in a data storage 
unit 42 and allows immediate access to this information by 
the shipper 20, the carrier 22, and other authorized users. 
This reduces the administrative costs of the shipper 20 and 
the carrier 22. The central processor 40 interfaces with an 
23 improved payment system including an issuing institution 
44 and a paying institution 52. An issuing processor 45 of the 
issuing institution 44, maintains a credit account for the 
shipper 20 and debits the shipper's account for the cost of 
the shipment. Apaying processor 54 of the paying institution 
30 52 tenders payment to the carrier 24. 

FIG. 2 is a block diagram illustrating an example flow- 
chart for programming the shipper processor 24 of FIG. 1 
according to the present invention. According to this 
35 example flowchart, the shipper processor 24 receives 200 an 
input of relevant purchase order information for storage and 
processing using an adequate input device 202. Using a 
conventional desktop PC for example, a keyboard and 
mouse are adequate input devices. Using a more complex 
4Q computer arrangement, a digital retrieving device, such as an 
information scanner, is used to offset some of the labor 
associated with this inputting effort. 

The shipper processor 24 processes 204 the purchase 
order information including referencing inventory control 
45 and customer information systems to generate 206 shipment 
parameters. In a particular application, the shipment param- 
eters include the identity of the carrier, identity of the 
receiver, the number of units, the weight of the shipment, the 
destination of the shipment, the date of shipment, and the 
50 estimated date of delivery. The shipper processor 24 is 
located at the shipper's premises so that the shipper proces- 
sor 24 receives accurate information resulting in further 
reliability and efficiency of the system. 
The shipper processor 24 electronically sends 208 the 
55 shipment parameters to the BOL rating engine 30. The 
transmission is accomplished conventionally. The BOL rat- 
ing engine 30 of the illustrated embodiment of FIG. 1, is 
designed to suit the needs of the particular shipper, the type 
of goods shipped, and to provide an interface to the shipper 
60 processor 24. Conventionally, BOL rating engines, which 
are in use today, are implemented using a computer pro- 
cessing device such as a stand-alone personal computer, a 
personal computer connected to a network, or a conven- 
tional mainframe. 
65 FIG. 2a is a block diagram illustrating an example flow- 
chart for programming the BOL Rating Engine 30 of FIG. 1 
according to the present invention. The BOL rating engine 
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receives 216 the shipment parameters and processes 218 the 
shipment parameters. The BOL Rating Engine 30 generates 
220 a rated BOL. The BOL rating engine 30 is programmed 
to an agreed upon rate structure by the shipper 20 and carrier 
22. As a result, the BOL rating engine 30 produces consis- 5 
tently rated BOL's. This has the further advantage that the 
shipper 20 and the carrier 22 do not have to audit the engine 
often. Existing systems require frequent auditing of the 
results of the BOL rating engine. With no post audit 
adjustments, the payment to the carrier 22 is definite. 10 

The BOL rating engine 30 sends 222 the rated BOL to the 
shipper processor 24. In a particular application, the BOL 
rating engine 30 is included in the shipper processor 24. The 
shipper processor 24 performs the rating function of the 15 
BOL rating engine 30 so that there is no need to send the 
shipment parameters to an external BOL rating engine. The 
shipment parameters are processed and a rated BOL is 
generated solely by the shipper processor 24. 

Another advantage associated with the process in which a 20 
rated BOL is produced is that only one BOL rating engine 
30 is needed for the entire shipment transaction system. This 
saves duplicate efforts by the carrier 22 and ensures exact 
payment. A significant benefit of this illustrated embodiment 2 , 
of FIG. 1 is that the cost depicted on the BOL is the final cost 
of shipment. Therefore, the shipper 20 and carrier 22 will 
immediately know the final cost of shipment before the 
goods are delivered. The BOL rating engine 30 removes 
ambiguity from the shipment transaction payment process 3 
which significantly offsets time consuming payment dis- 

The shipper processor 24 receives 212 the rated BOL and 
sends 214 the rated BOL to a shipper access terminal 32 
located at the shipper's premises. In an alternative 35 
embodiment, the BOL rating engine 30 is located off the 
shipper's premises so that the shipper processor 24 can 
access the BOL rating engine 30 on an as-needed basis. One 
advantage is that one standardized BOL rating engine could 
be electronically linked to multiple shipper processors 40 
thereby reducing the cost to each individual shipper. 

FIG. 3 is a block diagram illustrating an example flow- 
chart for programming the data processing device 34 of FIG. 
1 according to the present invention. The shipper access 
terminal 32 contains a data processing device 34 which 
receives 300 the rated BOL. The data processing device 34 
validates 312 the rated BOL to ensure that the rated BOL 
contains data which is complete, error-free, and properly 
formatted. The data processing device 34 processes 312 the , 
rated BOL and generates 316 a list of transaction informa- 
tion. The transaction information includes the information as 
seen in table 1 below. The columns in Table 1 represent the 
following: Data Element is the data that will reside in that 
particular element location, Length is the length of the data , 
element; type is the type of data element which is either 
numeric or alpha-numeric, and Description simply describes 
the function of the data element if necessary. 



TABLE 1-continued 



Length Type DESCRIPTION 



N Record ID, 



reporting 

rrier Alpha Code, a 
idardized carrier 



Carrier Vendor 



Customer PO # 

Vendor Order 
Number 



Reference B/L #1 15 AN Consolidated Shipments 

Reference B/L #2 15 AN Consolidated Shipments 

Reference B/L #3 15 AN Consolidated Shipments 

Bill of Lading 1 AN Reporting 



Inbound, Outbound 



Prepaid, Collect 
Flag 

COD Flag 
COD Amount 
Shipment Value 
Driver Name 
Trailer/Car # 
Trailer/CarSeal# 
Import, Export 

# s!o s 

Stop off Charges 
Rated Freight 
Charges 



Accessorial 

Total Freight Chgs 
Destination Name 



Mileage 



Length Type DESCRIPTION 



Shipper ID 

Dock ID 

Bill of Lading # 



The data processing device 34 sends the transaction 
3 information to a central processor 40. In one embodiment, 
the data processing device 34 is implemented using a 
conventional personal computer programmed to operate 
under the control of an operating system stored in the 
memory. These types of computer arrangements are not 
5 presently programmed to conventionally interface with a 
central processing center and a processing device located at 
a shipper's premises. One advantage of interfacing the 
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central processor 40 with shipper access terminal 32 is that 
the shipper access terminal 32 can control the quantity, 
quality, and timing of information that is transmitted 
between the shipper processor 24 and the central processor 
40. The access terminal 32 can also control the communi- ; 
cation sessions between the shipper processor 24 and the 
central processor 40. The shipper access terminal 32 is 
designed so that the shipper 20 may directly access the 
transaction information. The shipper 20 will not be allowed j 
to make changes to the transaction information, but is able 
to add additional information. This ensures the integrity of 
the transaction information. An additional advantage of the 
access terminal 32 is that the data processing device 34 can 
receive real-time information from the shipper processor 24 1 
regarding the shipment transaction. 

In an alternative embodiment, the shipper access terminal 
32 is linked to a magnetic stripe card reader. The card reader 
accepts a card and transmits the data contained therein to the 2 
data processing device 34 of the shipper access terminal 32. 
The magnetic stripe card reader accepts an identification 
card from a user of the system. The identification card 
contains relevant user information. In an alternative 2 
application, the access terminal 32 is linked to a bar code 
reader which is designed to receive information from a bar 
code and input the bar code information into the data 
processing device 34. The bar code is printed on the BOLor 
on a carrier identification card. 3 

The data processing device 34 sends 318 the transaction 
information to the central processor 40. The design of the 
central processor 40 is dictated by the desired speed, the 
number of users, and the amount of data tc 



DATA ELEMENT 



Shipper Profile 
WIDTH TYPE 



Account ID 

Shipper Name 
Shipper Address 1 
Shipper Address 2 
Shipper City 



Uniquely identifies a legal entity 
using a single BOL system, 
assigned by the CP 40. 
Account # assigned to shipper 
20 by issuing processor 54. 



Automatically supplied by CP 



Valid values are OPEN, CLSD, 
HOLD. Automatically updated 
on effective date if effective 
date was pre-entered or as part 
of on-line transaction when 
effective date is set to today. 



Pending Status 
Effective Date 



is updated, YYYYMMDD 



re OPEN, CLSD, HOLD 



FIG. 4 is a block diagram illustrating an example flow- 
chart for programming the central processor 40 of FIG- 1 to 
manipulate the transaction information according to the 
present invention. The central processor 40 receives 402 the 
transaction information and performs 404 an integrity check 4 
on the incoming information to ensure that the information 
is correctly formatted and contains no errors. If the integrity 
check is unsuccessful, the transaction information is stored 
in a suspense file in a data storage unit 42. Once the error is ^ 
corrected, the corrected transaction may be sent into the 
normal process flow. If the integrity check is successful, the 
central processor 40 retrieves 406 authorized user profile 
lists from the data storage unit 42. 

The data storage unit 42 is essentially a memory unit 5 
which stores information relevant to the shipping transac- 
tion. The design of the data storage unit 42 is dictated by the 
amount of data needed to be stored. 



An authorized carrier profile list identifies information 
regarding the carrier 22 and the shipment transaction as can 
be seen below in table 3. Included in the carrier profile is a 
merchant number which a paying processor 54 assigns to the 
carrier 22. Each carrier 22 can have multiple merchant 
numbers if desired. This allows carrier flexibility to assign 
different merchant numbers for different regions or different 
shippers. This flexibility facilitates the carrier's business 
management process. It is not known of existing systems 
which provide such flexibility. 



The authorized user profile lists represent the users and 
combination of users that are authorized to use the system. 
Authorized user profile lists include a shipper profile list, a 
carrier profile list, a carrier/shipper profile list, and a shipper 
access terminal profile list. The profile fists provide the cross 
reference between the payment ID (assigned by central 
processor 40), an account ID (assigned by an issuing pro- 
cessor 45), and a merchant number (assigned by a paying 
processor 54). Carrier 22 Nam, 

An authorized shipper profile list identifies information 65 carrier Address 
regarding the shipper and the shipment as can be seen below Carrier city 
in Table 2. 



COLUMN NAME WIDTH TYPE DESCRIPTION 



' SCAC 



4 character code that uniquely 
identifies a Carrier 22. 
Paying processor 54 assigns to 



9 
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TABLE 3 -continued 



TABLE 4-continued 



COLUMN NAME 



State/Province 
Carrier Country 



Last Update User 



A/N Name of primary contact at 
Carrier HQ 
N Phone number of primary co 
tact at Carrier HQ 



YYYYMMDD format 
Automatically supplied by CP 
40 when first BOL record is 

Carrier 22^ YYYYMMDD 
format 

Automatically updated by 



Automatically updated by CP 40 
when current status field is 
updated, YYYYMMDD format 



future date. YYYYMMDD 

ed by CP 40 
■ed by CP 40 



Wid values are OPEN, CLSD, 
HOLD. Automatically updated 
on effective date if effective date 
was pre-entered or as part of on- 
line transaction when effective 
date is set to today. 
Automatically updated by CP 40 
when current status field is 
updated, YYYYMMDD format 
User will key status 
Default to today's date with user 
ability to override to a future 
date. YYYYMMDD format 
Automatically stamped by CP 40 
Automatically stamped by CP 40 
HHMM format 

Automatically pulled from user 
profile lists 



Aii authorized shipper access terminal profile identifies 
the shipper 20 as well as the shipping dock. A shipper has a 
separate shipper access terminal profile for each dock. The 
central processor 40 assigns a different dock ID for each 
dock. The information included in the access point profile is 
listed below in table 5 



TABLE 5 



An authorized shipper/carrier profile list identifies infor- 
mation regarding valid shipper carrier combinations as can 
be seen below in table 4 



COLUMN NAME WIDTH TYPE DESCRIPTION 



Shipper ID 
5 Dock ID 



Uniquely identifies a legal entity 
using a single BOL system 
Uniquely identifies a particular 
physical dock location with a 
shipper ID. 

Issuing Processor 54 assigns. 
Defaults from shipper profile, 



Shipper/Carrier Profile 



COLUMN NAME 



Shipper ID 
Carrier SCAC 
Merchant Number 



Delivery (POD) 
Type of POD 



"Y" for POD to be required, 
"N" for POD not required 
Identifies in what manner the 
POD is to be received. 
Number of days after which the 
transaction will close and be 
paid to the Carrier 22 regardless 



ot POD hs 



ically supplied by CP 
YYYYMMDD format 



N To be used for reportin 



40 when 



ed by CP 

YYYYMMDD format 
Automatically supplied by CP 
40 when first BOL record is 

YYYYMMDD format 
Automatically updated by CP 40 
every time a BOL record is 
processed 

Automatically updated by CP 
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processor 45 stores 507 the approved authorization request 
TABLE 5-continued and decreases 508 the open-to-buy. The issuing processor 45 

; sends 510 the authorization approval to the central processor 

Access Terminal' Profile 4 q md me processor 40 updates the records in the 

NAME width type description 5 data stora g e um t 42. If the authorization is successful, the 

payment ID is considered "authorized". If the authorization 

to today. Valid values are unsuccessful, the issuing processor 45 sends 512 an 

rrzation dechne to the central processor 40. 
as fteld'is After the goods are delivered to a receiver, the payment 

updated, YYYYMMDD format io id must be "closed". Closed refers to providing proof of 
delivery (POD) of the shipment in order to complete the 
shipment transaction. POD includes the identity of the 
snipper, the BOL number, the carrier invoice number, the 
delivery date and time, the person acknowledging receipt, 
id by CP 40 15 and ^ CO n(3ition of the shipment. A carrier processor 46 



OPEN, CLSD, HOLD 
Current Status 6 N Automatically updated by CP 40 



Default to today's date with us 



A/N Automatically pulled from us 



s the POD and sends the information to the central 
processor 40. 

le embodiment, the carrier processor 46 is a conven- 



The central processor 40 authenticates 408 the transaction 20 tional bar ^ «* d "" ^ bar code reader is used by the 
m rarnftr 11 tr, read a bar code on the shipment. The bar code 



information by comparing elements of transaction informa- , , , 

tion with the authorized user profile lists. The elements of ™ der sends the P0D "Nation <° central processor 
the transaction information used for authentication include; 

the identity of the shipper, the identity of the shipper's dock, In an alternative embodiment, the carrier processor 46 is 

and the identity of the carrier. If the authentication is 25 a voice response unit 48 (VRU). FIG. 6 is a block diagram 

successful, the central processor 40 assigns 410 a payment illustrating an example flowchart for programmmg the VRU 

identification number (payment ID) to the transaction infer- 48 according one embodiment of the present invention. In 

mation and stores 412 the transaction information in the data this embodiment, the central processor 40 extracts an open 

storage unit 42. The payment ID is a unique key for the payment ID from the data storage unit 42. The central 

transaction record which the central processor 40 uses to ,„ processor 40 sends information relating to the open payment 

centrally track the transaction. The payment ID includes ID > including the BOL number and the shipper ID, to the 

specific information regarding the shipment transaction VRU 48. The VRU 48 receives 602 the open BOL number, 

including; the shipper identification number, the BOL A standard touch-tone telephone is used to access the 

number, and the shipping date. The advantage of the pay- VRU 48 While the location of the telephone is not critical, 

ment ID is that it allows the central processor 40 to more 35 locating it at the receiver's premises promotes efficiency, 

efficiently and accurately track the different actions occur- convenience, and accuracy. It is convenient and efficient 

ring within the system. The payment ID can be referenced to because the carrier 22 can call the VRU 48 at the exact time 

the specific identification numbers which any of the users the shipment is delivered. It is accurate in that the phone 

may assign. The payment ID is now considered "open". number of the receiver, automatically captured by the VRU 

Open is a term used to signify that the shipper 20 has 40 48, will identify where and when the call was made, 

transferred the goods to the carrier 22, and the carrier 22 has The VRU 48 prompts 604 the carrier 22 for the shipper 

not yet completed the shipment. ID. The VRU 48 receives 606 the shipper ID and attempts 

If the authentication is unsuccessful, the central processor to match 608 the entered shipper ID with a open shipper ID. 

40 stores 414 the invalid transaction in a suspense file in the If the shipper ID is matched, the VRU 48 prompts 610 the 

data storage unit 42. When an invalid transaction is stored, 45 carrier 22 for the BOL number. The VRU 48 receives 612 

a notification is sent which indicates that an error has the entered BOL number and attempts to match 614 the 

occurred and is in need of further review and correction. combination of the entered BOL number and shipper ID 

Once the error is corrected, the corrected transaction may be with an open BOL number and Shipper ID. If the BOL 

sent into the normal process path. number and shipper ID combination is matched, the VRU 48 

The central processor 40 sends the authenticated transac- so prompts 616 the carrier 22 for condition of shipment. The 

tion information, including the shipper identity and the cost VRU 48 receives 618 the condition of shipment and sends 

of the shipment, to an issuing institution 44 for authoriza- 620 the POD information which includes BOL number, the 

tion. FIG. 5 is a block diagram illustrating an example shipper ID, and the condition of the shipment to the central 

flowchart for programming the issuing processor 45 of FIG. processor 40. 

1 to perform an authorization check according to the present 55 If the VRU 48 cannot match either the shipper ID and the 

iuing institution 44 contains an issuing BOL number, the VRU 48 prompts 622 the carrier 22 to 



processor 45. The issuing processor 45 maintains accounts either try again or routes 624 the c 
for one or more shippers. Each account includes information service where the problem can be resolved, 
regarding credit limits, open authorizations, unpaid FIG. 7 is a block diagram illustrating an example flow- 
balances, and the resulting open-to-buy. Open-to-buy mea- 60 chart for programming the central processor 40 of FIG. 1 
sures the unused credit limit. generating a deposit file according to the present invention. 

The issuing processor 45 receives 502 the authorization The central processor 40 receives 702 the matched BOL 

request from the central processor 40. The issuing processor number, the shipper ID, and the condition of the shipment 

45 compares 504 the authorization request to the open-to- from the carrier processor 46. The central processor 40 

buy of the shipper and attempts to approve 506 the request. 65 validates 704 the incoming data to ensure that it is error free 

If the shipper 20 has enough open to buy, the issuing and properly formatted. The central processor 40 extracts 

processor 45 approves the authorization request. The issuing 706 the open payment ID from the data storage unit 42. The 
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central processor 40 authenticates 708 the matched BOL One advantage associated with the generation of pay- 
number with an open payment ID. If the BOL number and ments to the carrier 22 is that the carrier 22 is paid relatively 
payment ID are authenticated, the payment ID is considered soon after the carrier 22 has completed the shipment. This 
complete. The central processor stores 710 the completed provides the carrier 22 with improved cash flow and reduces 
transaction and corresponding payment ID in the data stor- 5 the carrier's working capital requirements. Another advan- 
age unit 42. If authentication is unsuccessful, the central tage is that the carrier 22 does not have to audit or rate the 
processor 40 stores 712 the information in a suspense file payment which saves time and money. This streamlined 
where the problem can be manually resolved as discussed approach-reduces the carrier's administrative costs associ- 
above. ated with processing a payment. 

A payment ID can be completed by the above manner, or 1Q The paying processor 54 generates 814 a systems bill for 

a payment ID can expire. A payment ID expires when a the carrier 22. This systems bill represents the amount the 

pre-programmed number of days has elapsed since the carrier 22 owes for the service provided by the system of the 

shipping date. This preprogrammed number of days is present invention. The paying processor 54 sends 816 the 

defined as auto close days in the data storage unit 42. A systems bill to the carrier 22. The paying processor 54 sends 

particular transaction is identified by the shipper and carrier 818 the systems bill information to the central processor 40 

to expire on a specific date, the effective date, whether or not 15 where the information is stored in the data storage unit 42. 

the proof of delivery is received. On the effective date, the The paying processor 54 delivers 820 the paid shipment 

payment process begins. This has the advantage that the transactions to the issuing processor 45 of the issuing 

carrier 22 will be paid for every shipment carried. Payment institution 44. 

to the carrier 22 is expedited if proof of delivery is received. ^ The issuing institution 44 maintains one or more accounts 

The central processor 40 periodically extracts 714 from for the shipper 20 and extends and manages credit to the 

the data storage unit 42 the transactions that are listed as shipper 20. The issuing processor 45 maintains the amount 

"completed and authorized" or "expired and authorized." paid to each carrier 22 on behalf of each shipper 20. FIG. 9 

The central processor 40 sorts and batches 716 the transac- is a block diagram illustrating an example flowchart for 

tions by the merchant number. The central processor 40 2J programming the issuing processor 45 of FIG. 1 to credit a 

generates 718 a deposit file 50 for those authorized trans- transaction according to the present invention. The issuing 

actions which are completed or expired and which have not processor 45 receives 902 the paid transactions from the 

been previously extracted. In a particular application, one paying processor 54. The issuing processor 45 retrieves 904 

deposit file 50 is created for all transactions completed by the approved authorization list and compares 906 the autho- 

each carrier. The deposit file 50 is formatted so that it is 3Q rization list with the paid transactions. The issuing processor 

compatible with the paying processor's 54 format. The 45 attempts to match 908 the paid transactions with an 

deposit file 50 includes the payment ID, the account ID, the authorized transaction. If a match is made, no change is 

carrier identity, the BOL number, the destination city, the made to the open to buy. If a match is not made, the issuing 

destination state, the destination zip code, and the cost of processor 45 decreases 910 the open to buy. 

shipment. The cost of the shipment represents the amount 35 The issuing processor 45 posts 912 the cost of shipment 

that is owed by the shipper 20 and payable to the carrier 22. for all paid transactions to the shipper's account thereby 

The central processor 40 performs 720 a general integrity increasing the balance due from the shipper 20. The issuing 

check on the deposit file 50. The integrity check includes: processor 45 periodically bills 914 the shipper 20 for the 

ensuring that the payment ID has been authorized, ensuring posted financial transactions paid on behalf of the shipper 20 

that the BOL is completed or expired, and ensuring that 40 and periodically receives 916 payment from the shipper 20. 

payment has not yet occurred for the particular payment ID. When the issuing processor 45 receives payment, the pro- 

If the central processor 40 validates the deposit file 50, the cessor 45 posts payment to the shipper's account and 

processor 40 sends 722 the deposit file 50 to a paying increases 918 the open-to-buy. 

processor 54 of a a paying institution 52. In a particular The issuing processor 45 communicates with the central 
application, the deposit file 50 is conventionally sent via a 45 processor 40 and sends information regarding shipper 20 
telephone transmission. The paying institution has a paying payment and billing. The central processor 40 updates the 
processor 54 which processes financial information and data storage unit 42 with this information, 
maintains financial accounts for the carrier 22. The paying In an alternative embodiment, the paying institution 52 is 
processor 54 is generally designed to process financial incorporated into the issuing institution 44. This results in 
information. The paying institution 52 maintains one or so one processor performing the functions of the issuing pro- 
more accounts for each carrier 22. cessor 45 and the paving processor 54. 

FIG. 8 is a block diagram illustrating an example flow- A further advantage of the computer processing system 

chart for programming the paying processor 54 of FIG. 1 for a shipment transaction involving a shipper and a carrier 

according to the present invention. The paying processor 54 is that the data storage unit 42 and central processor 40 

receives 802 the deposit file 50 and sends 804 a confirmation 55 interface to store and provide value-laden information to the 

message to the central processor 40 that the deposit file 50 users of the system. The central processor 40 provides a 

was received. security check for all information entering and leaving the 

The paying processor 54 validates 806 the incoming data storage unit 42. The central processor edits incoming 

deposit file and generates 808 payment to the carrier 22. The files and provides on-line alarms for duplicate files, stale 

paying processor 54 tenders 810 payment to the carrier 24 60 dated files, out of balance files, and files with corrupt data, 

and sends 812 this information to the central processor 40 so The central processor 40 maintains a suspense file in the data 

that the central processor 40 can update the data storage unit storage unit 42 where incoming invalid transaction infor- 

42. In a particular application, the paying processor 54 mation and unmatched proof of delivery information are 

tenders payment by directly paying the carrier 22. In an stored. With a centrally located suspense file, the problem 

alternative embodiment, the paying processor 54 sends the 65 resolution process is more efficient, 

payment to the carrier's bank conventionally through the The central processor 40 maintains data views and tables 

Federal Reserve's Automated Clearing House. and stores this information in the data storage unit 42. The 
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central processor 40 maintains a BOL Header Table for each 
BOL number which generally includes a summary of all 
information relating to that shipment transaction. This infor- 
mation is shown in the table 6 below. The source of the 
particular data element is indicated in column four of table : 



N CP 40 
N CP 40 

N CP 40 Record ID; reporting 
AN Shipper Record ID 
N Shipper Record ID, reporting 
A Shipper Alternate index, 

identifies Carrier 
N CP 40 Alternate index, 

for CP 40 usage 
N Shipper Alterna 

Shipper to specify its 
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TABLE 6-continued 



Merchant # 
Vendor # 



Shipper Name 
Shipper Contact 

Shipper Phone # 

Designator 



Shipment Mode 
Inbound, 
Outbound Flag 
Prepaid, Collect 

COD Flag 
COD Amount 
Shipment Value 
Driver Name 
Trailer/Car # 
Trailer/Car Seal # 



Charges 
Cube Dirrn 



Toiam-eight 
Charges 

Destination Name 




BOL Header Data Elements 
Length Type Source Purpose 



AN Shipper Alternate index, 



N Shipper reporting, verification 

N Shipper reporting, verification 

N Shipper reporting, verification 

N Shipper reporting 

AN CP 40 inquiry 

N Shipper Life cycle tracking 

N CP 40 Life cycle tracking 

N CP 40 Life cycle tracking 

N CP 40 Life cycle tracking 

N CP 40 Life cycle tracking 

Proc. 45 response feed 

AN Issuing From authorization 

Proc. 45 response feed 

N CP 40 Life cycle tra 

N CP 40 •" 

N CP 40 Life cycle tracking 

N Paying From Settlement record 

AN Paying From Settlement record 

N Issuing From statement billing 
Proc. 45 file feed for life 

N Carrier POD tracking, claims 
Proc 

N Carrier POD tracking, claims 
Proc. 46 

N Carrier POD tracking, claims 
Proc. 46 

A Carrier POD tracking, claims 



AN Shipper Consol 
AN Shipper Consol 
AN Shipper Report: 



LTL, TL, RAI, AIR. 



AN 



Shipper reporting 
reporting 



Shipper t . 

AN Shipper reporting; claims 

AN Shipper Reporting; Claims 

AN Shipper reporting; claims 

AN Shipper reporting; claims 

AN Shipper reporting 

N Shipper reporting 

AN Shipper reporting 

AN Shipper payment, reporting 



item details generally consist of information relating to the 
, goods of the shipment as can be seen below in table 7. 



BOL Line Item Detail Data Elen: 



AN Shipper ] 
AN Shipper > 



ayment, reporting 
ayment, reporting 



AN Shipper reporting 
AN Shipper reporting 
A Shipper reporting 



Shipper 
Shipper 



$N Shipper 
AN Snipper 
N Shipper 



AN Shipper reporting 
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TABLE 7-continued 



BOL Line Item Detail Data Elements 



Data Element Length Type Source Purpose 

Item Freight 7.2 N Shipper reporting, 



In the example system application of FIG. 1, the carrier 22 i 
will not have access to the BOL line item product value, but 
will be able to see the line item freight charges. 

A further advantage of the shipment transaction system of 
FIG. 1 is that the system allows multiple users to obtain 
information about the same shipment from the same source. 3 
Since the system supplies information from the same source, 
all users will obtain the same information at the same time. 
This advantage of timeliness does not exist in current 
systems. Existing systems are not known to provide a single 
source of up-to-date information regarding multiple ship- ' 
ment transactions. 

In an alternative embodiment, multiple users access the 
shipment information via the central processor 40. The 
shipment information is stored in the data storage unit 42. 
The central processor 40 is electronically linked to a mul- 
titude of user stations. The link between the central proces- 
sor 40 and a user station allows for conventional two-way 
communication. The user station is a standard personal 
computer comprising of a video display, a keyboard, a 
central processor, and a modem link. A user initiates a 
request for information by accessing the central processor 40 
using the personal computer. When the user is logged into 
the central processor 40, the central processor 40 prompts 
the user to enter a password. 

The central processor 40 provides a security check on all 
information requests. The security check is programmed 
such that the shipper 20 and carrier 22 are restricted to 
accessing only their own data. In addition, the processor 40 
is programmed such that unauthorized parties are denied 
access. 

The central processor 40 receives informational requests 
from the user. The central processor 40 accesses the data 
storage unit 42 and extracts the requested information and 
transmits the information to the user's station. The advan- 
tage of such an information service is clear. Users will be 
able to obtain current information regarding a shipment 
transaction. 

In a particular application, once a user has access to the 
system, the central processor 40 will prompt the user for a 
range of dates of interest including the current day, the 
previous day, monthly total, yearly total, or a specified date 
range. The central processor 40 displays the transaction 
information, freight amounts, shipment costs, total weight, 
and cost per pound for various types of transactions includ- 
ing: transactions added to the data storage unit, transactions 
with proof of delivery, transactions that have expired, trans- 
actions in the suspense file, transactions paid to carrier, 
transactions in transit, transactions declined, and transac- 
tions approved. 

The central processor 40 allows user's to request a 
particular transaction by entering any one of a multitude of 
transaction elements. The central processor 40 identifies a 
particular transaction with reference to the BOL number, the 
shipper's customer number for the receiver 22, the payment 
ID, the carrier's customer number for the shipper 20, the 
merchant number, the account ID, the receiver's order 
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number for the shipper 20, the shipper's order number for 
the BOL number, or the shipping date. This ensures com- 
patibility between the user reference numbers such that the 
user can access information using their unique reference 
; number assigned to the transaction. 

The example application has additional advantages. The 
central processor 40 provides to all authorized users the 
ability to generate custom analysis of their own data. This 
has the advantage of giving the carrier 22 the ability to 
0 extract payment data needed to automatically post his 
accounts receivable system. This is an advantage over 
existing systems which rely on manual distribution of pay- 
ment against the account receivable system. Similarly, the 
shipper can extract payment data and automatically post his 
5 accounts payable which closes out the individual accounts 
payable due to each carrier. An advantage stemming from 
this automated system is that the shipper 20 does not need 
a paper invoice in order to have proof of delivery. The 
shipper 20 accesses the central processor 40 and verify 
■° which shipments have been delivered by a particular carrier 
22. Similarly, the carrier 22 accesses the central processor 40 
to find out which transactions have been paid out by the 
shipper 20. This informational system removes much uncer- 
tainty from the shipment process which promotes more 
efficient use of available resources such as working capital, 
transportation, and personnel. 

In a particular application, the central processor 40 gen- 
erates standard shipment transaction summary reports and 
provides appropriate access to the reports by various users. 
These reports include a transaction inventory control report, 
an open aging summary report, a suspense inventory control 
by source report, and a suspense inventory aging summary 
report. The central processor 40 uses the security profiles to 
determine which subset of transaction records will be sum- 
marized for each user. For example, the shipper 20 has 
access only to that shipper's reports. 

The inventory control report provides control totals of 
BOL numbers, merchandise value, and freight value. There 
are key control points including: starting inventory position, 
new BOL's from shippers, BOL's closed since the last 
report by the different methods discussed for closing BOL 
numbers, BOL's re-opened since the last report by manual 
proof of delivery override via customer service, BOL's 
canceled since the last report, and the ending inventory 
position. 

The open aging summary report contains those BOL 
numbers that have not been delivered. In addition, the 
freight value and merchandise value for each shipper ID and 
Dock ID are supplied for distinct age groups. The age groups 
include groupings by consecutive days since the shipping 
date and one group for 10 days past the shipping date. The 
suspense inventory control by source report includes mer- 
chandise and freight value amounts of transactions in the 
suspense file. Several control points for the suspense inven- 
tory control include: starting inventory position, new inven- 
tory added since last report, inventory cleared since last 
report, inventory deleted since last report, inventory unde- 
leted since last report, and ending inventory position. The 
i suspense inventory aging summary report provides an aged 
summary of suspense files including the merchandise and 
freight value of items that are in the suspense file by original 
receipt date. 

The central processor 40 generates detailed reports 
; including: the inventory aging detail report, the suspense 
inventory aging detail report, and the declined item aging 
detail report. The detail reports are viewed by either the 
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arrangement programmed and configured to process the 
transaction information by storing an authorized profile list 
criterion that includes information about authorized users, 
by determining whether the transaction information satisfies 
5 the authorized profile list criterion, and by using the autho- 
rized profile list criterion to generate information for audit- 
ing a transaction between said one of a plurality of shippers 
and said one of a plurality of carriers. 
6. A shipment transaction system, according to claim 5, 
number, carrier ID, freight value, and the merchandise value. 10 further including means for informing the central processor 
The declined item aging detail report allows users to arrangement of delivery of the goods by the carrier, the 
research the cause of exception items and lists the shipper ID central processor arrangement being responsive to the 
combination, ship date, authorization time, BOL number, informing means and using the transaction information and 
shipper invoice number, merchant number, and freight the authorized profile list criterion to audit the shipment 
value. The declined itemjiging detail report is viewed by 15 transaction and payment thereof. 



shipper ID/Dock ID/account ID combination or by the 
carrier ID/merchant number combination. The inventory 
aging detail report lists the open BOL numbers sorted by the 
days in inventory, the shipper ID combination, and the BOL 
number. The inventory detail report lists the merchandise . 
and freight value associated with each open BOL number. 
The suspense inventory aging detail report lists open BOL 
numbers by source and receipt date. Several fields are 
displayed including: shipper ID, dock ID, account ID, BOL 



r by 



either shipper ID/dock ID/account ID combination, 
carrier ID/merchant number combination. 

The central processor 40 generates two reports that ref- 
erence declined authorizations. These reports include the 
declined item summary report and the declined item aging 20 
report. The declined item summary report summarizes infor- 
mation regarding the declined authorization. The declined 
item aging report summarizes the information regarding the 
declined authorization by the shipping date. 

Accordingly, the present invention provides, among other 25 
aspects, a computer processing system for a shipment trans- 
action involving a shipper and a carrier. Other aspects and 
embodiments of the present invention will be apparent to 
those skilled in the art from consideration of the specifica- 
tion and practice of the invention disclosed herein. It is 30 
intended that the specification and illustrated embodiments 
be considered as exemplary only, with a true scope and spirit 
of the invention being indicated by the following claims. 

What is claimed is: 

1. For shipment transaction processing involving trans- 35 
action information related to goods shipped from one of a 
plurality of shippers by one of a plurality of carriers, a 
shipment transaction system comprising: a central processor 
arrangement programmed and configured to maintain data 
relating to an authorized profile list criterion that includes 40 
information about authorized users, and programmed and 
configured to process the transaction information by deter- 
mining whether the transaction information satisfies the 
authorized profile list criterion, and using the authorized 
profile list criterion to generate information for auditing a 45 
transaction between said one of a plurality of shippers and 
said one of a plurality of carriers. 

2. A shipment transaction system, according to claim 1, 
further including a computer arrangement that is pro- 
grammed and configured to respond to shipment-related 50 
information from an external device by generating a set of 
transaction information. 

3. A shipment transaction system, according to claim 2, 
further including means for informing the central processor 
arrangement of delivery of the goods by the carrier the 55 
central processor arrangement being responsive to the 
informing means and using the transaction information and 
the authorized profile list criterion to audit the shipment 
transaction and payment thereof. 

4. A shipment transaction system, according to claim 1, 60 
wherein the central processor arrangement is further pro- 
grammed and configured to update a previously-created 
authorized profile list criterion. 

5. A shipment transaction processing involving transac- 
tion information related to goods shipped from one of a 65 
plurality of shippers by one of a plurality of carriers, a 
shipment transaction system comprising: a central processor 



7. A shipment transaction system, according to claim 6, 
further including a computer arrangement that is pro- 
grammed and configured to respond to shipment-related 
information from an external device by generating a set of 
transaction information. 

8. A shipment transaction system, according to claim 7, 
wherein the central processor arrangement is further pro- 
grammed and configured to update a previously-created 
authorized profile list criterion. 

9. A shipment transaction system for processing transac- 
tion information related to goods shipped from one of a 
plurality of shippers by one of a plurality of carriers, the 
shipment transaction system comprising: 

a computer arrangement that is programmed and config- 
ured to respond to shipment-related information from 
said one of the shipper by generating a set of transac- 
tion information that includes at least one transaction 
code to identify the transaction and the time at which 
the shipment is initiated at the shipper's premises; and 

a central processor arrangement located remote from the 
shipper's premises and programmed and configured to 
respond to the transaction information, maintain an 
authorized profile list criterion, and determine whether 
the transaction information satisfies the authorized pro- 
file list criterion, the central processor arrangement 
being responsive to a notification of delivery of the 
goods by the carrier and using the transaction informa- 
tion and the authorized profile list criterion to audit the 
shipment transaction. 

10. For shipment transaction processing involving trans- 
action information related to goods shipped from one of a 
plurality of shippers by one of a plurality of carriers, a 
shipment transaction system comprising: 



means for maintaining data relating to the authorized 
profile list criterion, and for processing the transaction 
information by determining whether the transaction 
information satisfies the authorized profile list criterion, 
and using the authorized profile list criterion to gener- 
ate information for auditing a transaction between said 
one of a plurality of shippers and said one of a plurality 
of carriers. 

11. For shipment transaction processing involving trans- 
action information related to goods shipped from one of a 
plurality of shippers by one of a plurality of carriers, a 
shipment transaction system comprising: 

means for storing an authorized profile list criterion that 

includes information about authorized users; and 
means for processing the transaction information by stor- 
ing the authorized profile list criterion, by determining 
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whether the transaction information satisfies the autho- 
rized profile list criterion, and by using the authorized 
profile list criterion to generate information for auditing 
a transaction between said one of a plurality of shippers 
and said one of a plurality of carriers. 5 

12. A shipment transaction system for processing trans- 
action information related to goods shipped from one of a 
plurality of shippers by one of a plurality of carriers, the 
shipment transaction system comprising: 

a means for responding to shipment-related information 10 
from said one of the shipper by generating a set of 
transaction information that includes at least one trans- 
action code to identify the transaction and the time at 
which the shipment is initiated at the shipper's pre- 
mises; and ' 1 5 
a CPU means, located remote from the shipper's 
premises, for responding to the transaction information, 
for maintaining an authorized profile list criterion, and 
for determining whether the transaction information 
satisfies the authorized profile list criterion, the CPU 20 
means being responsive to a notification of delivery 
of the goods by the carrier and using the transaction 
information and the authorized profile list criterion to 
audit the shipment transaction. 

13. For shipment transaction processing involving trans- 25 
action information related to goods shipped from one of a 
plurality of shippers by one of a plurality of carriers, a 
method for monitoring a shipment transaction comprising: 

providing an authorized profile list criterion that includes 3Q 
information about authorized users; 

using a computer arrangement, maintaining data relating 
to the authorized profile list criterion and processing the 
transaction information by determining whether the 
transaction information satisfies the authorized profile 35 
list criterion, and by using the authorized profile list 
criterion to generate information for auditing a trans- 
action between said one of a plurality of shippers and 
said one of a plurality of carriers. 

14. A method for monitoring a shipment transaction, 40 
according to claim 13, further including sending shipment- 
related information from an external device and generating 

a set of transaction information therefrom. 

15. A method for monitoring a shipment transaction, 
according to claim 14, further including informing the 



computer arrangement of delivery of the goods by the 
carrier, and using the computer arrangement to audit the 
shipment transaction and payment thereof in response to the 
transaction information and the authorized profile list crite- 



16. A method for monitoring a shipment t 
according to claim 15, further including updating a 
previously-created authorized profile list criterion. 

17. For shipment transaction processing involving trans- 
action information related to goods shipped from one of a 
plurality of shippers by one of a plurality of carriers, a 
method for monitoring a shipment transaction comprising: 

providing an authorized profile list criterion that includes 
information about authorized users; 

using a computer arrangement, processing the transaction 
information by storing the authorized profile list 
criterion, by determining whether the transaction infor- 
mation satisfies the authorized profile list criterion, and 
by using the authorized profile list criterion to generate 
information for auditing a transaction between said one 
of a plurality of shippers and said one of a plurality of 



18. A method for monitoring a shipment ti 
according to claim 17, further including sending shipment- 
related information from an external device and generating 
a set of transaction information therefrom. 

19. A method for monitoring a shipment transaction, 
according to claim 18, further including informing the 
computer arrangement of delivery of the goods by the 
carrier, and using the computer arrangement to audit the 
shipment transaction and payment thereof in response to the 
transaction information and the authorized profile list crite- 
rion. 

20. A method for monitoring a shipment transaction, 
according to claim 19 further including updating a 
previously-created authorized profile list criterion. 

21. A method for monitoring a shipment transaction, 
according to claim 20, further including sending shipment- 
related information from an external device and generating 
a set of transaction information therefrom. 
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